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I serve the Earth. 


Introduction 


This book is targeted to STEM (Science, Technology, Engineering, 
and Mathematics) educators and administrators. It is intended to 
show how robots in particular, and engineering projects in general 
can be applied to their STEM program. It is a train-the-trainer 
document, pointing out sources of information and support to the 
teaching professional who knows how to present the material at the 
appropriate level. 


This book covers the topic of small mobile robotic sensor 
platforms for environmental data collection. They are ideally suited 
for STEM programs, and to get the students involved in many 
issues of science. 


We can stare at computers all day, but the project that gets up off 
the workbench and walks out of the room gets your attention. Kids 
are interested in things that move. Let's use that to stimulate their 
imaginations. 


This book cover things that fly, float, sink, and travel on land, and 
serve as science sensor platforms. All of the hardware is available 
commercially. Some complete assemblies are available. Platforms 
can operate in differing environments, such as amphibious units, 
and serve as co-operating units, such as a bot with an associated 
drone. That's NASA's idea for the next Mars lander.. Drones can 
serve as communication relays for robots on the ground, and in the 
water. 


What do these platforms do? That I can't tell you. Use your 
imagination, and let the students use theirs. This activity is not to 
build robots, or drones, or boats. It is to develop sensor platforms 
that return real data, that can provide answers to real questions. 
Actually, the scope is extremely broad, and I have limited it to 
projects for planet Earth. I have another book on STEM-Sats in 
orbit that can do the same thing from a better vantage point, and 


yet another that shows how to implement the same type of 
missions to other planets. Let the student's imaginations run wild, 
but keep it real. 


Author 


The author has a BSEE in Electrical Engineering from Carnegie- 
Mellon University, and Masters Degrees in Applied Physics and 
Computer Science from the Johns Hopkins University. During a 
career as a NASA support contractor from 1971 to 2013, he 
worked at all of the NASA Centers. He served as a mentor for the 
NASA/GSFC Summer Robotics Engineering Boot Camp at GSFC 
for 2 years. In that effort, we deployed a Greenland Rover, or 
GROVER, to measure the ice thickness, and do trending to see if it 
is receeding or accumulating. He teaches Embedded Systems for 
the Johns Hopkins University, Engineering for Professionals 
Program. 


Having a very good grasp of the technical topic, he does not, 
however, have a clue on how to present it to anyone below the 
level of advanced undergraduate. Thus, he is writing this book to 
“train the trainers.” This will suggest topics, although the best 
topics come from the students themselves. It will also provide 
information and pointers to information for STEM educators. 
Building a robot for exploration nowadays is cheap, fairly easy, 
and grabs the attention of the students. 


This books will be updated frequently, and there will be an 
associated website. 


What is STEM? 


STEM (Science, Technology, Engineering, Mathematics) is the key 
to the United States' continued dominance in High Technology. It 
took a lot of expertise to implement the first cell phone. Now they 
are turned out like cookies. 


STEM addresses overall education policy and curriculum sources 
in schools, at critical grade levels. 


Although the teachers are experts in their particular area, and know 
how to present grade-appropriate material, they may not know how 
to access the resources they need, or where to get help in a 
particular area. 


STEM programs are seen as vitally important in the education 
system, world-wide. It is getting to be a complex, interconnected 
ecosystem. Advances in the subject areas of STEM will take place 
only if you know how to exploit this ecosystem for knowledge. 


When I was in school at the STEM age, before STEM was 
invented, I had an encyclopedia. Today, students can access 
WikiPedia from their smart phones. The focus has changed from 
knowing facts, which are at you fingertips on demand, to 
leveraging facts to innovate. This approach touches all of the 
academic disciplines, the Humanities, Languages, Art, besides the 
STEM topics. Perhaps the best skill set to have is good internet 
search skills. Teachers have had to transition from asking factual 
questions, to asking questions that derive from online research. I 
certainly have. 


I think that small robotics can be a major focal point for STEM, 
embracing a wide variety of topics at the cutting edge of 
technology and science. I have a handful of technical degrees, and 
spent 42 years at the various NASA Centers. I teach Electrical 
Engineering courses world-wide, and have done specialty robotics 
and embedded systems courses at the undergraduate and graduate 
level. It is time to apply that expertise earlier in the education 
program. I think the best way is to support the educators. 


My idea is, a practical robotics project brings together all of the 
interesting pieces to provide a focal point for student work. There 
is a massive body of support material available and I have taken on 
the task of making STEM educators aware of this vast treasure- 
trove of resources. 


STEM is a critical resource for understanding and implementing 


the future. I think the small robotics paradigm is a good thing to 
introduce into STEM. Let's do this. Future generations of STEM- 
mies will thank us. 


The STEM fields are those academic and professional disciplines 
that fall under the umbrella areas represented by the acronym. 
According to both the United States National Research Council 
(NRC) and the National Science Foundation (NSF), the fields are 
collectively considered core technological underpinnings of an 
advanced society. In many forums (including _ political, 
governmental and academic) the strength of the STEM workforce 
is viewed as an indicator of a nation's ability to sustain itself. 


The Science, Technology, Engineering, and Mathematics 
Education Coalition works to support STEM programs for 
teachers and students at the U.S. Department of Education, the 
National Science Foundation, and other agencies that offer STEM 
related programs. 


FIRST 


FIRST (For Inspiration and Recognition of Science and 
Technology) is an organization founded by inventor Dean Kamen 
in 1989 to develop ways to inspire students in engineering and 
technology fields. The organization is the foundation for the FIRST 
Robotics Competition, FIRST LEGO League, Junior FIRST LEGO 
League, and FIRST Tech Challenge competitions. 


The FIRST® LEGO® League is an international competition 
organized by FIRST for elementary and middle school students. 
Each year, a new challenge is announced that focuses on a different 
real-world topic related to the sciences. The robotics part of the 
competition revolves around designing and programming LEGO 
Robots to complete tasks. The students work out solutions to the 
various problems they are given and then meet for regional 
tournaments to share their knowledge, compare ideas, and display 
their robots. FIRST LEGO League is a partnership between FIRST 
and the LEGO Group. It also has a scaled-down robotics program 


for children ages 6-9 called Junior FIRST LEGO League. 


What is an Enviro-bot? 


I'll define an Enviro-bot, since I made the word up up (invented it. 
sounds better). It is a small mobile platform that collects data 
autonomously in one or more domains, urban, aerial, 
water/underwater, or forest/mountain/desert. It is limited to the 
surface of Earth, in the atmosphere, or on or under the water. It is 
small, inexpensive, and can be done by k-12 students. It may 
deceivingly look like a toy, but it is not. It is the focus of a project 
in science and engineering, on a mobile robotics platform. 


A lot of Jargon and acronyms are used in these fields, so I have 
included a Glossary at the end to help with this. The Internet is also 
a big help. 


Robots, and Tele-Robots 


“Man is the lowest cost, 150-pound, non-linear, all-purpose 
computer system that can be mass-produced by unskilled labor.” 
Attributed to a NASA official. 


Today’s robot systems are deaf, nearly blind and stupid. Yet, we 
expect them to operate safely in an unstructured environment. But, 
they are getting better, as technology advances, driven by fields 
such as self-driving cars. 


Robots are handicapped in terms of mobility and manipulation, 
sensory input, cognitive processing, learning, and the application 
of experience. However, they have better computational capability, 
better communications capability, fewer environmental constraints, 
and, perhaps, fewer ethical issues. (Leaving aside the issue of 
military armed robots). 


What are the problem areas in the applications of robots? 
Accuracy, which has both a mechanical and a sensor component; 


dynamic performance, a speed/dexterity trade-off, addressed by 
more robust control algorithms, sensor systems in terms of 
integration and procession; interactive control, starting with 
modeling, standardization and modularization. None of these are 
insurmountable problems, and the advance of technology addresses 
all. 


Robotic systems need better world models. They need to integrate 
and fuse sensor data into a better view of the world around them. 
They need more reasonableness assumptions, and a-priori 
knowledge of the physical world. They need flexibility of 
response. Learning from experience would be a major asset. What 
they need, then, is better software. 


The word robot is from the Czech robota, which means servant or 
laborer. It was coined by novelist Karel Capek in a 1917 short 
story. His 1920’s play R.U.R, Rossum’s Universal Robots, brought 
the term to the public eye. “Robot” was first applied to describe 
manipulator systems for manufacturing and the science fiction 
creations. A robot is a tool that is flexible and programmable. 


One definition often used is that a robot is a “programmable multi- 
functional manipulator designed to move materials, part, tools, or 
specialized devices through variably programmed motions in the 
performance of a variety of tasks.” It is completely autonomous 
once trained so that it can operate without further human 
intervention. It incorporates feedback in its operation. Telerobots 
increase the domain where useful works and observations can be 
done. They are human proxies in a hazardous environment, such as 
space, volcanoes, and nuclear plants. 


“Tele-“ is from the Greek, and means distant. A telerobot has a 
person in the control loop. A variation of this is with a much 
smarter telerobot, with Directed Autonomy. There is a spectrum of 
sense-control tasks, and as more of these are assigned to the 
telerobot system, it becomes more autonomous. Well-structured 
tasks can be accomplished autonomously, perhaps after training. 
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Telerobotics are robotic devices which incorporate mobility, 
manipulative and sensing capability, and are controlled remotely 
by a human. The issue is, the level of control. The human operator 
might individually operate each joint or mechanism, or he/she 
might just say, “go explore.” Telerobotics provide feedback to the 
operator, visually and by force-feedback. This leads to the mini- 
master model of hand control of manipulators in telerobots, 
developed in the nuclear industry. A telerobotic system, with a 
person in the loop, uses the best of both subsystems: the decision 
making and visual acuity of the human with the strength and 
dexterity, not to mention the ability to operate in hazardous areas 
capability of the robot system. 


Telerobotics have been used in a variety of applications for more 
than 50 years. The nuclear industry has the longest history of 
operational experience. Telerobotic systems operate in toxic 
chemical and biological environments and in research. Bomb 
disposal is an obvious area, with units deployed with local police 
forces being common. Remotely piloted vehicles are another area 
of telerobotics, and combat robots are increasing being deployed. 
Telerobots serve as prison guards and warehouse security. Some 
trains are telerobotically operated within the confines of industrial 
plants. 


Telepresense is the extension of a human’s senses to a remote 
location. This includes enhancement of the senses, such as a 
radiation detector, or night vision. Various aspects of the 
workstation design for the humans determine the effectiveness of 
the overall system. For example, should the cameras on the robotic 
system be slaved to the head motion of the operator? Our tools 
tend to have our capabilities in mind, so we work best with 
systems like us, bilaterally symmetric, for example. Having a 
three-armed robotic device, even though it would be very useful in 
many tasks, would be difficult for the human operate to get used 
to. From the task standpoint, a big, strong left arm and two 
dexterous right arms might be the correct choice, Telecontrol refers 
to the manipulation of the remote system by the human operator, 
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either by direct control of the remote mechanisms, or by higher 
level directives. 


Teleoperator systems have high adaptability and low autonomy, 
due to the person being an integral part of the control loop. This 
works well for a certain class of problems. Robots tend to have 
high autonomy for specific, well-defined tasks, but low 
adaptability. We can get to autonomous systems by added 
intelligence and perception to robotic systems, or adding a 
supervisory mode to the telerobotic systems. NASA has sent 
robotic systems into Space since the 1970’s. It could be argued that 
any spacecraft is a telerobot system, but we will take a narrower 
view. 


Domains 


Mobile robots can operate in many domains. With difficulty, they 
can be designed to operate in multiple, different domains. This 
section will discuss the unique challenges of the different 
environments. 


Ground 


Ground based robot explorers can use a variety of locomotion. 
This includes wheels, treads, legs, etc. The Mars rovers tend to be 
6 wheel vehicles, with each wheel operating independently under 
computer control. Legged locomotion is more complex to 
accomplish, but is more versatile in rough terrain. Hovercraft can 
be used, but they expend a lot of energy getting and staying 
airborne. They work well over ice, which is generally smooth, but 
not over sandy areas, where they create their own dust cloud. 
Wheeled systems are the simplest and easiest, although caterpillar 
track is needed in difficult terrain. It is less energy efficient. Many 
wheeled, tracked, and legged platforms are available in the 
marketplace. Larger systems might be derived from wheel chairs, 
carts, or other vehicles. The larger the chassis, the more the need 
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for built-in safety. Take this from a guy who was pinned to the wall 
by a 600 pound mobile platform, with a big red stop-now button, 
just out of reach. 


Underground 

The underground environment is challenging as well. We have to 
reach it through a natural or man-made opening — examples are 
caves, lava tubes, and mines. The environment might be water- 
filled, presenting another set of challenges. Communications is 
also difficult, and dragging a tether is usually not feasible. 


We could consider a water environment under ice. This is common 
in the Polar regions, and may be present on some of the moons of 
Jupiter and Saturn. Not much is know about the interface region 
between sea ice and the deeper saline water. There may or may not 
be an air layer under the ice. The salt water environment is 
corrosive to metals. Orientation and communications is difficult. 


One place that has been considered for robotic exploration is lava 
tubes. These can be found near most volcano's, and are known to 
exist on the moon. They are mostly cylindrical, and fairly regular, 
unlike caves subject to water action. 


Air 


Flying explorers can cover a lot of ground, with an increase in the 
energy expended. Winged systems can glide, minimizing energy 
expenditure. Balloon-borne payloads can be used. For low altitude 
and short-to- moderate duration missions, the quad-copter or hex 
copter configuration is good. The energy expenditure is high, and 
they are not quiet. 


Lighter-than-air systems typically use helium for the lift. They are 
usually vertical systems, and are at the mercy of the winds. 
Tethered balloon or aerostats can be also used. Very high altitude 
balloon platforms, free flying, can reach the fringes of space. There 
is sometimes a question of recovering the payload. Balloons are 
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less expensive than heavier-than-air craft. 


Aerobot is a term used for more sophisticated free-flyer packages. 
An Aerobot can be implemented in different technologies, heavier 
or lighter than air. Some lighter-than-air systems can stay aloft for 
30 days or more. A very simple tethered aerobot with just a 
camera to look down is an attention-getter. Add a few sensors such 
as temperature an humidity to round out the science. Very 
inexpensive drones that can fly themselves are available on 
Amazon. Some include cameras, and some payload-carrying 
capability. 


UAV's, or unmanned aerial vehicles, have applications in 
exploration. They have been used by the oil and gas industry to 
survey large areas for potential new resources. This generally 
involves geomagnetic sensing, looking for anomalies in the Earth's 
magnetic field which can be associated with underground cavities. 
In addition, drones with real-time video feeds can patrol long 
pipelines through remote areas looking for leaks. Similar uses can 
be found in the Electric Power Industry, for inspection of power 
lines in remote regions. There are manufacturers of commercial 
drones for commercial and scientific use. NASA operates an 
unarmed version of the General Atomics MQ-9 Reaper as part of 
its Environmental Research Aircraft and Sensor Technology 
(ERAST) Program. This program uses the aircraft for remote 
environmental sensing, monitoring of agriculture, severe storm 
tracking, and also serving as a telecomm relay platform. 


Water/underwater 


Water-based systems can be limited to the surface, or can be 
designed for sub-surface operations as well. Smart buoys, floating 
data platforms, can be tethered or drifting. Vast networks of smart 
drifting buoys are returning data on currents, ocean temperature 
and salinity, and other data for that 74 of the planet we don't have 
complete data for. They are generally solar powered. 
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For submersibles, the farther you go down, the more the pressure 
increases, and the greater the problem in keeping the water out of 
the vehicle. That having been said, submersibles have been to the 
deepest part of the ocean, and imaged weird life forms that thrive 
around volcanic vents. The farther you want to go down, the more 
expensive it is going to be. Platforms tend to be very specialized. 


Of special interest is the ice/water/land interface in Antarctica. 


There is an interesting open source project called OpenROV that 
involves a do-it-yourself fairly low cost telerobot underwater 
explorer. I would like someone in Australia to put a couple of these 
at the Great Barrier Reef, and allow teleoperation via the Internet. 
(reference: openrov.com). Let me know when that's ready. 


Here is an Arduino-based underwater robot: 
https://www.youtube.com/watch?v=FE53y2-t6V0 


Multi-Domain Systems 


Multiple domains systems have enhanced flexibility, at the cost of 
complexity. We can have, for example, a ground based system that 
can launch and recover a drone or aerostat. This provides a “god's 
eye view” of the area around the ground vehicle. This is useful for 
navigation and obstacle avoidance. We can also have an 
amphibious vehicle, that is equally mobile on the land, and water. 
Another multi-domain exploration vehicle might be deployed on 
an ice field, and drill through the ice to deploy a submersible. This 
is a focus of interest for exploration of some of the icy moons of 
the outer planets. 


Cooperative systems 


Rover systems can operate cooperatively in different domains. We 
are talking here of non-homogeneous units, designed to different 
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set of requirements. We might have a ground vehicle that could 
deploy a smaller scout vehicle. That would be useful in 
underground exploration and search and rescue as well as indoors. 
The larger vehicle might not be able to climb stairs, for example. 
We might have a ground vehicle being able to launch an air 
vehicle, to fly ahead and define areas of interest, or of danger, for 
the ground vehicle. There are many advantages to having an “eye 
in the sky.” This introduces the problem of having the air unit find 
the ground unit for a safe return landing. This can be solved with a 
beacon system or GPS navigation. The ground system can recharge 
the air asset's batteries upon landing via an umbilical or induction. 
The air system would be short range, and would need to be capable 
of vertical take-off and landing; i.e., a quadcopter. The ground 
based systems might also deploy and retrieve a tethered balloon. 


The concept is termed cooperative autonomy, and extends from 
cooperation between and among systems, to human-machine 
interaction (as in the case of tele-operation). Virtual sensor 
platforms can be enabled, where different platforms cooperate on 
simultaneous observations, from different points of view. 


Similarly, a waterborne systems could also make use of an air 
asset. The water borne system could also deploy a submersible. In 
one scenario, the waterborne systems goes to a predetermined 
location on a body of water such as a lake or bay, and deploys a 
small submarine craft for bottom sampling. 


Teams of non-homogeneous co-operating robots can optimize the 
search for data or items of interest. A ground-based rover can be 
vectored to a position of interest by an autonomous air vehicle. 
Swarms of small robots cover larger areas, and come together as 
required for items of interest. Smaller vehicles can be deployed 
from larger platforms as well. This might include dropping a 
ground vehicle from an air vehicle, or deploying a smaller land 
vehicle from a larger platform. 


Drones or balloons can serve as communication relays for ground 
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or water-based systems. 


Robot Swarms 


Let's talk about the birds and the bees for a moment. These 
groupings of animals exhibit what is termed swarm behavior, also 
seen in certain species of fish. This means the group moves as if of 
one mind. We have a group of homogeneous individuals, 
operating as one big virtual organism, a kind of spontaneous 
collective intelligence. It has its value in deterring predators, and 
hunting/feeding. A behavior emerges in the organisms' interactions, 
and their interaction with the environment. 


An agent, in the computer sense, is an autonomous entity that 
senses its environment, and is goal-seeking. It can also learn. An 
agent may be implemented in software, or can be a separate 
hardware-software system. 


We can use this cooperative behavior model in the control of a 
group of homogeneous robot systems. Swarm dynamics can be 
applied to coordinate multi-rover systems. First, the individual 
robots need to be aware of each other, and should be able to 
communicate. We don't need any one in charge. It is ad hoc 
groupings of diverse individual that come together to work on the 
same problem. Scalability extends to very large numbers of units. 


This section describes a different approach to exploration with 
collections of smaller co-operating systems that will combine their 
efforts and work as ad-hoc teams on problems of interest. 


Swarm behavior is based on the collective or parallel behavior of 
homogeneous systems. It is implemented as multiple co-operating 
software agents. This mimics collective behavior, modeled on 
biological systems. Examples in nature include migrating birds, 
schooling fish, and herding sheep. A collective behavior emerges 
from interactions between members of the swarm, and the 
environment. The resources of the swarm are organized 
dynamically. Swarm behavior is a group attribute across the 
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swarm. It relies on continuous co-ordination of behavior. Each 
member makes stochastic choices. There is a lack of authority in 
the Swarm, each member making local choices based on local 
conditions, based on a global rule set. Example rules are 
separation, avoid crowding; alignment, do what other swarm 
members are doing; and cohesion, move to the center of mass of 
the swarm. Swarm activity can be chaotic or orderly. Emergent, 
un-planned behaviors are seen in implemented systems. 


In Swarm systems, the key issues are communication between 
units, and cooperative behavior. The capability of individual units 
does not much matter; it is strength in numbers. Self-organizing 
behavior emerges from decentralized systems that interact both 
with members of the group, and the environment. Swarm 
intelligence is an emerging field, and swarm robotics is an active 
research topic. 


The swarm must be agile, able to respond to targets of opportunity, 
when they arise. Flexibility, and the ability to respond locally to 
unplanned events will be part of the architecture. A Swarm is an 
implementation of a multi-agent system, where the agents are 
implemented in program code. 


Short range radio communications will be used between the 
platform and the flyer. 


Approach 


An approach I have used involves identifying students with similar 
interests and forming teams to implement their projects. An ideal 
team size is around 3-5. At the higher levels, these teams self- 
organize. It will be necessary for some teacher organization 
intervention at the lower levels. It is essential to have each team 
member contributing, and learning from others. The teacher is the 
best judge of team organization. Try to keep all team members as 
contributors. The teacher is what I would call the Program 
Manager. He or she manages multiple Projects, each one of which 
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has a Project Lead. Under this lead are contributors, with skills in 
different areas. 


Let the students choose the mission. Get the students involved in 
suggesting appropriate missions. They will come up with Projects 
that are interesting and they want to do, but the Teacher/Program 
Manager needs to access these as to level of difficulty and cost. 


We had an interesting project one time for undergraduate 
engineering students. The goal was to drop an egg over a distance 
of one floor, and have it remain intact. The Janitors hate this one, 
but it get the students involved in many things...parachutes, lots of 
foam padding, retrorockets — you name it. 


Now, given the mission, we can select a platform, and trade-off 
whether it should be a ground vehicle, an air vehicle, or something 
in or on the water. How long does it have to operate? That tells us 
what kind and size of battery we will need. Will we add solar 
panels for additional range? (For a Greenland vehicle, we once 
added wind turbines.) How much power does our solution need? 
Well, we'll have to measure that, and decide on battery's 
accordingly. 


We can select sensors for our 'Bot. These might be for visible light, 
infrared, or ultraviolet. They might include temperature and 
relative humidity. Define the requirements, define the sensors 
needed. Maybe we want to measure the state of health of the 
vegetation. How do we do that? (Hint — NASA knows). I once 
worked on a project that measured the salinity of the oceans from 
orbit. Tricky, but it can be done. 


A wide range of inexpensive sensors that are easy to interface are 
available. 


Each team should have a selected project, and designs its own 


Mission logo, which is printed in color, and put on the students' 
engineering notebooks. Cost: $3-5 per student for an engineering 
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notebook. I like the Graph Composition style. Each team should 
also have a flash drive for its software and documentation. Cost: 


$5. 


How do we locate or keep track of the explorer? Should it have a 
GPS or a beacon? Does the platform have a compass module? 
How do we get the data? Is it stored in the robots memory, or 
broadcast? All these are trade-offs, and there is no one good 
answer. Get the students involved in a discussion, and let it be their 
choice, good or bad. It's said, in engineering, we learn more from 
failures than successes. 


Design phase 


Once we know what we want to do, and have an idea of how to do 
it, we start working on the overall architecture of the solution. This 
leads to an interesting set of side topics. 


What is Electricity? 

What is Voltage, Current, Resistance, and Ohm’s Law. 
What is a Circuit? 

What is Polarity? 

What are Digital Logic and logic levels? 

Analog vs. Digital sensors. 

How does a rechargeable battery work? 

How long will be battery last, and how do we know? 
How will we test the unit? 

How will we send it commands? 

How do we know where it is? 

Ete. 


Let me explain some approaches, that may make it easier First, 
have the students consider whether they are a scientist, or an 
engineer. A scientist seeks out new knowledge, and an engineer 
likes to build things. The scientist uses the Scientific Method, and 
the engineer relies on good System Engineering practice. Both of 
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these approaches work well in their own domains. Both skillsets 
are required on the project, both points of view. We might need a 
biologist on the Team. An artist could come in handy to decorate or 
camouflage the vehicle. And we need a technical writer who keeps 
the official project log book. 


Ok, do you want to build a robot so you can use it to explore some 
domain of interest, or do you have a domain of interest in mind 
you want to explore, and a robot platform is the best way to do it? 
Are you an engineer or a scientist? I are an engineer. 


There is a difference of approach in the two domains, but neither is 
right or wrong — they are synergistic. The scientist often asks the 
engineer to build the hardware and software, so he/she can focus 
on the problem. The engineer often needs the scientist to pose the 
problem for which the hardware/software needs to be built. 


Can you be both? Certainly. You won't be as good at either, but it 
works. Most scientists are hands-on enough to put together 
prototype hardware and software, but most also prefer to focus on 
the problem. Engineers are overjoyed to be presented with a 
project to build something that hasn't been done yet. 


Let me explain the distinction from a NASA perspective. In the 
early days of satellites, each was built from scratch, and each was 
different. It was quickly realized, however, that the same platform 
could support a variety of instruments. The commonality was the 
power system, the mechanical structure, the command and 
telemetry, and the attitude control. This lead to a common design, 
where the engineering part (“the bus”) was the same, and the 
instruments differed. There was a well defined interface, and 
defined services that the bus provided to the instruments. The bus 
didn't care about the instruments. They just provided data that was 
a pass-through. The bus could support missions both by the Earth 
scientists (they look down) and the astrophysicists (they look up). 
There was an economy of scale in reusing the design, and in 
support of missions. Commonality lead to reduced costs. 
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Let me mention the importance of mathematics. Both groups, 
engineers and scientists, use a lot of math. Scientists like it; 
actually, mathematicians really like it, and engineers use it as a tool 
. Include all the math you can; do all the hard problems at the end 
of the chapters. This is a good place to specify the project will use 
the metric system, but English units can also be included. 
Understand the conversions. 


Where do software developers fit it? Both scientists and engineers 
can develop software, and mathematicians are good at it as well. 
Software can be an art form, and a tool. It is necessary to enhance 
your skill with tools of all kinds. Today, most software is “canned” 
pieces of code form code libraries, glued together. The 
development environment of the robot will be a pc — the robot 
won't host its own development system. The real hard part comes 
in testing the software. Generally, the person who wrote it is not 
the right one to test it. Testing is an art form. One of my old bosses, 
a tester, told me that if the developers were really angry with you, 
you were doing your job as a tester. 


Choose your domain: 


Land, water, air, underwater. If you want high altitude, look into 
balloons and blimps. If you want a more expensive option, take a 
look at the Cubesat program. 


Radio controlled “toys” in all of these areas provide a ready-made 
platform, allowing you to focus on the smarts of the system. I 
recommend that you buy ready to use platforms initially, maybe in 
kit form. Producing your own vehicle is not making good use of 
your time and money. This will not be a vehicle design program, 
but rather a science platform mission. Use the existing platforms 
available — the research for the right one is a good student project 
in itself. Give them the requirements, and let them find and defend 
their choices. 


Develop your expertise. Get a small embedded computer board 
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(Arduino is good), Learn to develop code for it, and interface 
sensors and motors. Get it working on the workbench. 


Integrate your electronics with your platform, and go explore your 
domain of interest. Write up what you do, and share back with the 
community. Help those staring out. Enjoy the project. Go for it! 


Some Suggested Projects 


I keep a bucket list of projects, for students who need to do an 
independent study course. Most of these are high level ideas, that I 
leave to the student to address. This lets them apply the systematic 
“systems engineering process.” 


An interesting and inexpensive project is to build a robot 
manipulator dexterity testbed. Get an infant Busy-board, or build 
one on a piece of plywood with different fasteners and electrical 
and plumbing connections. See if the robot arm (which can be 
manually controlled by a student) can operate the various 
mechanisms. A more ambitious project would be to implement a 
stereo vision system, with image-recognition software. This is well 
withing the capabilities of a Raspberry Pi computer, which has a 
special high-speed camera interface, and an image processing 
pipeline with support software. 


Another interesting team-building project would involve a fairly 
large (meter-high or so) robot Greet-er for your lab. This could 
start off as a static model, maybe constructed from a cylindrical 
trash can with a domed “head.” It would simply sense some one in 
front of it, and play a canned presentation. After that is successful, 
we might give it simple mobility. Maybe a simple arm and gripper. 
Beyond that...well, leave it up to the student's imagination. 
“Welcome to my lab, Human person...” 


Projects with Science Objectives 


Autonomous water sampling from large bodies of water such as 
lakes and bays. The system should be able to take samples from 
various depths and locations, and return them for analysis. 
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Remotely deployed weather station. It can be airdropped or 
mobile. It could return temperature, humidity, and wind data on 
the periphery of a forest fire area. 


Flying platform, mid-altitudes, to collect and return air samples for 
lab analysis. They can be launched downwind of suspected 
polluters. They can also collect wind speed and direction 
information for potential wind farm sites. 


The best project ideas come from the students. They know what 
they want to do, and it is our job to help them do it. 


This is a little tricky, but makes for a good project. What about an 
autonomous fire-fighting robot? It locates the fire via infrared 
sensors, and responds with squirting water. Maybe for the upper 
grades. 


Enabling Technology 


The deployment of small yet capable robotic platforms is enabled 
by rapid advances in technology. These include enhanced 
computational and communication capabilities, new materials, new 
power sources, and the commoditization of advanced technology. 
Moore's law continues to enhance the capability of the technology, 
while simultaneously lowering the price. Building-block modules 
of increasing complexity can be used at the high school, and 
elementary school level. 


Self-monitoring and cross-monitoring 


Homeostasis refers to a system that monitors, corrects, and 
controls its own state. Our bodies do that with our blood pressure, 
temperature, blood sugar level, and many other parameters. 


We can have the embedded processor monitor its performance, or 
have two identical systems monitor each other. Each approach has 
problems. We can also choose to “triplicate” the hardware, and use 
external logic to see if results differ. The idea is, two outweigh one, 
because the probability of a double error is less than that of a 
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single error. 


In at least one case I know of, the backup computer erroneously 
thought the primary machine made a mistake, and took over 
control. It was wrong, and caused a system failure. 


Self-test software can be included, usually running as a 
background task. This might also send a “heart-beat” signal to 
another processor or logic. At the hardware level, we can include 
built-in self test (BIST). 


A special-purpose timer essential for embedded applications is the 
Watchdog. This is a free-running timer that generates a cpu reset 
unless it is reset by the software. This helps to ensure that the 
system doesn’t lock up during certain critical time periods, and the 
software is meeting its deadlines. This approach has saved many a 
system. 


If the watchdog is not reset, it generates an interrupt to reset the 
host. This should take the system back to a baseline state, and 
restart it. Hopefully, normal operations will resume. The embedded 
system can’t rely on a human operator to notice a fault in the 
operations or a “hung” system, and press the reset button. Many 
very remote systems, such as those in deep water or on the surface 
of other planets have successfully recovered from faults with a 
watchdog. 


The watchdog timer is implemented in hardware, and does it’s job 
without direct software intervention. If the software fails to reset 
the timer, the system reboots. This might simply reset operations 
and restart, or may include diagnostics before the system is 
restarted. So, who watches the watchdog? 


The Internet of Things (IoT) 


The next big idea in deploying embedded systems involves the 
integration of cheap embedded devices with web services. The 
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Internet of Things refers to smart connected objects, such as small 
embedded controllers, smart sensors, and smart actuators. We 
implement uniquely identifiable objects, with an addressing 
scheme, perhaps a URL. 


The very-low-cost, high-performance microprocessor-based em- 
bedded systems enable wide usage. The Internet and wireless allow 
complete distance-insensitive world-wide connectivity. Cloud 
servers allow access to “unlimited” datasets. 


We can have universal world-wide connectivity, using the (.net) 
framework, which is free and open source software. Net frame- 
work allows the embedded device to be a http client. It can access 
data, provide data, and access services. It handles the hard part 
with code for requests and the socket interface., and is off-the-shelf 
libraries. It is available per-programmed into flash, and provides 
access to a huge ecosystem. 


So now, not only people with desktops, laptops, tablets and phone 
can populate the Internet, along with the server/cloud architecture, 
but devices can as well. This concept of IoT just kicked off around 
2014, but has seen tremendous growth. It is estimated that there are 
more “things” on the internet, than people. These are event driven. 
There is some concern this whole structure will become non- 
deterministic, even practically. It's just too complex, and feeding 
upon itself. 


The applications are limited only by imagination. Nodes can be 
self-organizing. There is already a completely wired smart city in 
Korea, Songdo. Computers were built into the houses, streets ,and 
offices as part of a city-wide wide area network 


We need to architect and implement the IoT carefully. At least as 
long as we are in charge. It can provide a whole new world-wide 
platform for cyber-attacks. How can it be managed? Can it be 
managed? It is a rapidly evolving system, with positive feedback. 
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There are privacy concerns. Now that this is working, we can't put 
the Genie back in the bottle. We can only hold on, and hope to 
steer. Does the Internet of Things need us? 


The Internet of Things is built upon web-accessible embedded 
systems. More and more embedded systems are on the web. This 
allows to integrate cheap embedded devices with ubiquitous web 
services, accessible with wireless technologies. An example might 
be smart electric meters. Smart devices, including rovers, can 
access data, provide data, or access services. 


To make use of this concept, we need uniquely identifiable objects 
such as smart sensors, smart actuators, smart platforms. What is 
the identity scheme? The Uniform Resource Locater (URL) 
approach can be adopted We also need advanced connectivity to 
the Internet, which provides distance-insensitive world-wide 
connectivity. These are large areas of the Earth's surface where the 
Internet does not reach, but satellite links can be used, although 
this is an expensive approach. The polar regions enjoy good 
satellite communications due to a series of polar orbiting 
spacecraft. 


Free and open source software and collaborative development 
environments enhance the deployment process. There are standard 
software interfaces for communication protocols. 


Mobile platforms 


Many standard tracked, wheeled, and legged platforms are cheap 
and available, as well as conventional model aircraft and rotating 
wing aircraft on the Quad-copter pattern. Many radio-controlled 
models, boats, submersibles, electric aircraft, cars, and trucks are 
readily available and inexpensive. Maybe even consider a used 
powered wheelchair. These serve as the mobility platforms for 
integrating computational, sensor, and communication packages. 
These might be adequate for the job, or at least the proof-of- 


26 


concept prototype. This is another area where you don't have to 
(literally) reinvent the wheel. 


Platforms can be all-wheel drive, or just several of the wheels can 
be driven, with idlers at the other positions for stability. One 
unique approach is to have a self-balancing platform with one large 
ball. Self-balancing mobility platforms, starting with the Segway, 
have made this technology off-the-shelf. 


Sometimes, it is a better use of your time to buy a “toy” platform, 
and update it with your sensors, computer, and communications. A 
recent quick look on Amazon found a very capable drone for $67, 
with batteries an additional $20. There was also an amphibious 
tracked vehicle for $20, that uses standard batteries. Many radio- 
controlled trucks can easily be employed as robot platforms, and 
usually students are thrilled to donate their old ones for the project. 


Flight Platforms 


Flight platforms come in several configurations. The lighter than 
air craft include balloon payload, and aerostats, or blimps. For 
heavier than air craft, the choices are fixed wing, and rotary wing. 
Big advances have been made in small rotary wing craft, leading to 
the 4-bladed hex copter, and 6-rotor devices. The rotors can be 
tilted individually for attitude control, or in combination, for 
vertical or horizontal flight. The advantage of winged craft is that 
they can glide. Kite-borne payloads can also be used, but they are 
mostly at the mercy of the winds. Flapping wing systems have also 
been demonstrated, but are complicated. 


3-D Print Technology 

It is valuable at some time to have a 3D printer in the engineering 
lab. This provides a quick, relatively inexpensive way to turn 
students' concepts into tangible structure. This frame can then hold 
the computer, sensors, and battery. Open Source design software is 
available, and design files can be uploaded to a 3-D printing 
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service for implementation. In the long run, investing in a 3-D 
printer will pay benefits down the line, as it is used in other 
projects. If the student can envision it, it can be printed. This is an 
awesome capability to have. 


Also, we can break the ‘bot down into two main parts — the 
platform consisting of the power, control, radio, structure, and 
mobility and the science payload. Essentially, the first part, 
referred to as the bus, can be common across missions, supporting 
different science instruments (the payload). This is great as all the 
buses can be built essentially the same. However they must support 
the science requirements for pointing, stability, electrical power, 
and data storage and transmission. In addition, it makes the science 
platform portable across different mobility platforms. 


Advanced battery and motor technology 


Batteries have gotten better, due to new applications in cars, small 
electric aircraft, boats, and cell phones. 


Rechargeable batteries in new chemistries are also the outgrowth 
of hybrid and full electric vehicles. The energy density is very 
high. Technologies like lithium-polymer (LiPo) have expanded the 
operating life of equipment before recharging is required, and 
allow for solar recharge. These types of batteries were used in 
consumer electronics by 1995. 


They also have the advantage of being lightweight. They also 
provide a higher discharge rate (greater current) than other battery 
technologies. However, overcharge, over discharge, and 
penetration can result in explosion. Special charging circuits are 
required, as well as temperature and discharge current monitoring. 


Embedded processors 


Very-low-cost, high-performance microprocessor-based embedded 
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systems enable wide applications. Most of these boards, complete 
32-bit computers with memory and I/O, and cost less than $50. 
Add-on boards provide GPS location finding, wifi and bluetooth 
connectivity, 3-axis gyros, a wide variety of sensors, and motor 
control, via PWM. 


Advances driven by cellular phones and data systems have made 
available small powerful processors that rival a datacenter of a few 
years back. They are designed for communication, and include a 
variety of standard interfaces. The devices are multicore, meaning 
there is more than one cpu. They can include specialty cores such 
as floating point or digital signal processing, They have memory 
integrated with the cpu. They support analog as well as digital 
interfaces. The boards tend of be deck-of-cards size or smaller, and 
typically cost under $50. Some examples include the Arduinos, 
Raspberry Pi, and BeagleBone board. 


A Microcontroller is a single chip cpu (or cpu's). memory, and I/O 
solution. Many different variations form a single cpu architecture 
(such as ARM), exist, giving the designer the flexibility to choose 
hardware to meet his or her requirements. 


This section presents and discusses some “real-world” embedded 
systems, at both the chip and system-level, that can be applied to 
robotic platforms. 


Arduino 


The Arduino is a simple open-source single-board microcontroller. 
The hardware consists of a simple open hardware design for the 
Arduino board with an Atmel processor and on-board I/O support. 
The software support includes a standard compiler and a boot 
loader that runs on the board, along with numerous libraries of 
code. 

Arduino hardware can be programmed using a language similar to 
C++ with some simplifications and modifications, and an IDE. The 
Arduino project began in Italy in 2005 to produce a device for 


29 


implementing student-built design projects less expensively. 


An Arduino board consists of an 8-bit Atmel AVR microcontroller 
or an 32-bit ARM. An important aspect of the Arduino is the 
standard way that connectors are arranged, allowing the CPU 
board to be connected to a variety of interchangeable add-on 
modules called shields. Shields allow for interfacing with sensors 
and actuators, as well as general I/O. Most boards include a 5-volt 
linearvoltage regulator and a 16 MHz crystal oscillator although 
some designs dispense with the on-board voltage regulator. An 
Arduino's microcontroller comes with a boot loader that simplifies 
uploading of programs to the on-chip flash memory. 


Now the Arduino architecture has been expanded into 32-bit 
versions, using the ARM Cortex MO and M3. Thirty-two bits 
makes it easier to do complex computations. 


Boards are programmed over an RS-232 serial connection. Serial 
Arduino boards contain a simple inverter circuit to convert 
between RS-232-level and TTL-level signals. Newer Arduino 
boards are programmed via serial communications over USB. The 
Arduino board brings out the microcontroller's I/O pins for use by 
external circuits. 


The Arduino IDE is a cross-platform application implemented in 
Java. It is designed to introduce programming to newcomers 
unfamiliar with traditional software development. It includes a 
code editor, and is also capable of compiling and uploading 
programs to the board with a single click. There is generally no 
need to edit makefiles or run programs on the command line. 


The Arduino Integrated Development Environment (IDE) comes 
with a C/C++ library called "Wiring", which makes many common 
input/output operations much easier. It uses the gnu toolchain and 
AVR libraries. The Atmel development Studio can also be used. 
Arduino programs are written in a variant of c/c++. 
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The Arduino hardware reference designs are distributed under an 
Open Source Creative Commons Attribution Share-Alike 2.5 
license and are available on the Arduino Web site. The source code 
for the IDE and the on-board library are available and released 
under the GPL (v2) license. The Arduino design has influenced 
many other similar devices. 


The Raspberry Pi 


The ARM processor has taken an impressive place in the 
embedded microcontroller world. The Roomba vacuum is based on 
the ARM architecture. The Raspberry Pi is a small, inexpensive, 
single board computer based on the ARM architecture. It is 
targeted to the academic market. It uses the Broadcom BCM2835 
system-on-a-chip, which has a 700 MHz ARM processor, a video 
GPU, and currently 512 M of RAM. It uses an SD card for storage. 
The Raspberry Pi runs the GNU/linux and FreeBSD operating 
systems. It was first sold in February 2012. Sales reached 4 
million units by the Fall. Due to the open source nature of the 
software, Raspberry Pi applications and drivers can be downloaded 
from various sites. It requires a single power supply, and dissipates 
less than 5 watts. It has USB ports, and an Ethernet controller. It 
does not have a real-time clock, but one can easily be added. It 
outputs video in HDMI resolution, and supports audio output. I/O 
includes 8 general purpose I/O lines, UART, I2C bus, and SPI bus. 
The Raspberry Pi design belongs to the Raspberry Pi Foundation in 
the UK, which was formed to promote the study of Computer 
Science. 


The Raspberry Pi 2, model B+ is a powerhouse chip, with a quad- 
core 32-bit ARM Cortex A7, running at 900 MHz. It also has a 
dedicated video processing pipeline. It has 512k of sram, and uses 
micro-sd cards (flash memory). It has 17 digital I/O lines, and 4 
serial ports. The board is 3.3 x 2.25 inches in size. 


Software 
There is a variety of off-the-shelf software solutions for the small 
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embedded processors boards. You don't have to ask, “what 
language do I program that in?” The choices as c-like and Java- 
like. Generally, you get an Integrated Development Environment 
that allows you to stitch together routines from code libraries.. 
Sometimes, you can do this graphically. You also can use the 
traditional coding model, for high level languages or assembly. 
There are many third-party development platforms that address 
coding for multiple architectures. 


The Integrated Development Environment (IDE) is a software tool, 
generally hosted on a pc, to develop, download, and test code on 
the target embedded system. This is a set of tools for compilation, 
debugging, simulation, and code version control. 


Usually, a rich selection of library routines are provided as well. 
IDE’s usually include a source code editor. Some IDE’s support 
multiple languages. The output of the IDE will be a code “load” 
that can be sent to the embedded system, or put into a non-volatile 
memory. It will include a boot loader to get things started. An IDE, 
hosted on a desktop machine with a large set of resources, 
represents a cross-tool for embedded target code development. 
Web-based IDE’s are emerging. These run in a standard browser. 


Open Source versus Proprietary 


This is a topic we need to discuss before we get very far into 
software. It is not a technical topic, but concerns your right to use 
(and/or own, modify) software. It’s those software licenses you 
click to agree with, and never read. That’s what the intellectual 
property lawyers are betting on. 


Software and software tools are available in proprietary and open 
source versions. Open source software is free and widely available, 
and may be incorporated into your system. It is available under 
license, which generally says that you can use it, but derivative 
products must be made available under the same license. This 
presents a problem if it is mixed with purchased, licensed 
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commercial software, or a level of exclusivity is required. Major 
government agencies such as the Department of Defense and 
NASA have policies related to the use of Open Source software. 


Adapting a commercial or open source operating system to a 
particular problem domain can be tricky. Usually, the commercial 
operating systems need to be used “as-is” and the source code is 
not available. The software can usually be configured between 
well-defined limits, but there will be no visibility of the internal 
workings. For the open source situation, there will be a multitude 
of source code modules and libraries that can be configured and 
customized, but the process is complex. The user can also write 
new modules in this case. 


The Open Source Initiative (www.opensource.org) maintains the 
definition of Open Source, and certifies licenses. 


The GNU General Public License (GPL) is the most widely used 
free software license. It guarantees end users the freedoms to use, 
study, share, copy, and modify the software. Software that ensures 
that these rights are retained is called free software. The license 
was originally written by Richard Stallman of the Free Software 
Foundation (FSF) for the GNU project in 1989. The GPL is a 
copyleft license, which means that derived works can only be 
distributed under the same license terms. This is in distinction to 
permissive free software licenses, of which the BSD licenses are 
the standard examples. Copyleft is in counterpoint to traditional 
copyright. Proprietary software “poisons” free software, and 
cannot be included or integrated with it, without abandoned the 
GPL. The GPL covers the GNU/linux operating systems and most 
of the GNU/linux-based applications. 


A Vendor’s software tools and operating system or application 
code is usually proprietary intellectual property. It is unusual to get 
the source code to examine, at least without binding legal 
documents and additional funds. Along with this, you do get the 
vendor support. An alternative is open source code, which is in the 
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public domain. There are a series of licenses covering open source 
code usage, including the Creative Commons License, the gnu 
public license, copyleft, and others. Open Source describes a 
collaborative environment for development and testing. Use of 
open source code carries with it an implied responsibility to “pay 
back” to the community. Open Source is not necessarily free. 


The Open source philosophy is sometimes at odds with the 
rigidized procedures evolved to ensure software performance and 
reliability. Offsetting this is the increased visibility into the 
internals of the software packages, and control over the entire 
software package. Besides application code, operating systems 
such as GNU/linux and bsd can be open source. The programming 
language Python is open source. The popular web server Apache is 
also open source. 


ROS 


The Robot Operating System is a set of software routines, libraries, 
and tools. It is open source software. It supports perception and 
object recognition, gesture recognition, mobile robotics, and 
planning, among other features. 


Computer Languages 


The c language is an ANSI and ISO standard. Many embedded C 
environments differ from pure ANSI C, and only provide subsets 
of the language. They also provide extensions which allow more 
direct control over hardware. Aspects of C which do not fit target 
architecture well are left out. 


Java is an object-oriented language with a syntax similar to that of 
c. The language is compiled to bytecodes which are executed by a 
Java Virtual Machine (JVM). The JVM is hosted on the computer 
hardware, and is an instruction interpreter program. Thus, the Java 
language is independent of the hardware it executes on. The JVM 
has also been instantiated directly in hardware. 
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The JVM is a software environment that allows bytecodes to be 
executed. There are standard libraries to implement the 
applications programming interface (API). These implement the 
Java runtime environment. Other languages besides Java can be 
compiled into bytecode, notably Pascal, ADA, and Python. JVM is 
written in the c language. 


The JVM can emulate and interpret the instruction set, or use a 
technique called Just in Time (JIT) compilation. The latter 
approach provides greater speed. The JVM also validates the 
bytecodes before execution. 


The bytecode is interpreted or compiled. Java includes an API to 
make up the Java runtime environment. Oracle Corporation owns 
Java, but allows use of the trademark, as long as the products 
adhere to the JVM Specification. The JVM implements a stack- 
based architecture. Code executes as privileged or unprivileged, 
which limits access to some resources. 


In the embedded world, you are working very close to the 
hardware. At times, you may need to delve into assembly 
language. You may need to write a device driver (horrors!). As 
opposed to general languages such as c or Java, the assembly 
language is unique to the hardware architecture. The concepts are 
generally the same across assemblers for different architectures. A 
statement in assembly usually maps directly to one machine 
language instruction, where a statement in a higher order language 
would result in multiple machine language instructions. 


c and Python languages 


The c programming language is general purpose, and maps well to 
the architecture of many machines. It requires a compiler, a 
program that takes the c program you wrote (“source code’), and 
transforms it into ones and zeros that the computer will understand. 
It allows you to define data items in different formats, and do 
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jumps and branches in your code, as well as data dependent 
branches (branch on zero). 


It is an ANSI standard, and, like most language it has nouns 
(variables) and verbs (action words). Several references books on 
the c language are included in the bibliography of this book. You 
can master the basics of programming in c in just a few hours on 
the computer. Getting good at it takes longer. You might also 
encounter a variant, called c++, which is more complex, but also 
more powerful. For the little embedded systems boards used in the 
robot, a pc-class machine will be needed for developing software. 
Then, a usb connection can be made between the little computer 
and the pc, to download the code. This USB cable can then be used 
to see messages from the embedded board. 


The Python language is particularly easy to use. It is an interpreted 
language, meaning there is an interpreter program running on the 
embedded computer, and it does not need to be compiled. It is 
open source software. Python is a general purpose higher order 
language. It comes with most Gnu-Linux distributions now. There 
are many interpreters and compilers available for Python. It can be 
used as an object-oriented or function/procedural language. Python 
has expressions similar to those of Java, and there is a large 
standard library of routines. 


Several reference works on both c and Python are included in the 
Resources section. Keep in mind this is a robotics course, and if 
you try to teach programming, you'll run out of time. Find out who 
the good programmers are, and let them teach the others. 


LOGO 


A very interesting computer language came out of MIT a while 
back. It was specifically to control robots, and was very simple, 
which is to say, they hid the complexity. So simple, pre-schools 
could get their robots to do what they wanted. I am not sure if any 
modern versions exist. Try this as a_ starting point: 
https://turtleacademy.com/ 
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Standards 


There are many Standards applicable to robotic systems. These 
range from general computer standards to embedded-specific 
embedded standards. Why should we be interested in standards? 
Standards represent an established approach, based on _ best 
practices. Standards are not created to stifle creativity or direct an 
implementation approach, but rather to give the benefit of previous 
experience. Adherence to standards implies that different parts will 
work together. Standards are often developed by a single company, 
and then adopted by the relevant industry. Other Standards are 
imposed by large customer organizations such as the Department 
of Defense, or the automobile industry. Many standards 
organizations exist to develop, review, and maintain standards. 


Standards exist in many areas, including hardware, software, 
interfaces, protocols, testing, system safety, security, and 
certification. Standards can be open or closed (proprietary). 


Hardware standards include the form factor and packaging of 
chips, the electrical interface, the bus interface, the power 
interface, and others. The JTAG standard specifies an interface for 
debugging. 


In computer architecture, the Instruction set architecture (ISA) 
specifies the instruction set and the operations. It does not specify 
the implementation. Popular ISA’s are x86 (Intel) and ARM 
(ARM Holdings, LTD). These are proprietary, and licensed by the 
Intellectual Property holder. 


In software, an API (applications program interface) specifies the 
interface between a user program, and the operating system. To run 


properly, the program must adhere to the API. 


Computer language standards also exist, such as those for the 
ANSI c, Python, and Java languages. 


37 


Networking standards include TCP/IP for Ethernet, the CAN bus 
from Bosch, and IEEE-1553 for avionics. 


It is always good to review what standards are and could be 
applied to an embedded system, as it ensures the application of 
best practices from experience, and interoperability with other 
systems. 


The Portable Operating System Interface for Unix (POSIX) is an 
IEEE standard, IEEE 1003.1-1988. The standard spans some 17 
documents. POSIX provides a Unix-like environment and API. 
Various operating systems are certified to POSIX compliance, 
including BSD, LynxOS, QNX, VxWorks, and others. 


Systems Engineering Process 


The system engineering process is a methodology of implementing 
complicated projects. It starts with the enumeration of 
requirements — what is it that the system has to do? This applies at 
the systems level, and will be allocated to parallel paths in the 
software and hardware. Design methodologies involve a plan and a 
process for creating a system to meet requirements. The more 
complex the system, the more complex are the plans. The process 
is the key. This applies equally to aqueducts, cathedrals, and Lego 
Robots. 


The design flow describes the sequence of steps in implementing 
the design methodology. There are various industry standard 
methodologies and models that have proved useful in large and 
complex projects. I have a separate STEM book out on the details 
of “the Engineering Process.” the following are the highlights. 


We should apply a sound system engineering process to your 
project. We start by defining our requirements, which will mostly 
derive from the environment that we want the rover to operate in. 
We might be cost or time constrained, which will drive the choices 
for build or buy. We can keep the cost low and the schedule intact 
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if we integrate a lot of existing parts, such as mobility platforms 
and small computer boards. 


We can develop a set of “strawman” requirements for our Earth 
explorers. To these would be added the requirements from the 
specific environment domain the explorer has to operate in. 


Requirements 


Collecting the requirements, we are defining, “What is the 
question?, What are we trying to do here?” We are the customer. 
But, before we go very far down the path of implementation, we 
should have a good idea what exactly it is we are trying to 
accomplish. 


The requirements flow-down into more detailed levels, such as the 
functional requirements, the Safety requirements, the interfacing 
requirements, the security requirements, and such things as size, 
weight, power, waterproof-ness, radiation tolerance....etc. And 
some of these requirements may be at odds with others. Delivery 
time is a requirement. So is maintainability. Sometimes, even 
color. 


The more time we spend on the requirements, and _ their 
ramifications, the easier the rest of the task will be. 


What is/are out Domain(s) of operation. Are humans in the 
vicinity? This will drive the safety requirements. 


What is the Operation duration? Do we expect the robot to be on 
its own for hours, days, weeks, or months? Do we anticipate 
unattended operation? 


Will our communications be upon opportunity or continuous? 


What is feasible for the link? Will wifi be available, or do we need 
an expensive satellite modem?. For certain underwater 
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applications, we might use a tether. 


What about ease of deployment? Do we need a truck, boat, or a 
helicopter to get the rover where it's going to operate? 


Consider Testability - Limit complexity by design and you enhance 
testability. Define the testing strategy. Consider Built-In Self Test 
(BIST). 


We built it, how do we test it? 


How much redundancy do we need and can we _ support? 
Redundancy involves extra size, weight, and power. 


One we get our essential requirements together, we can define 
certain derived requirements from these. This would include 
factors such as: 


Size, weight, power source, platform, mobility options, computing 
resources, communication resources, environmental: thermal 
range, moisture, radiation exposure, etc. 


What support infrastructure will the rover need? How do we get it 
back if it get stuck, or fails in the field. For the Greenland Rover, 
which goes off on its own for weeks at a time, I said that if it 
failed, the least senior person would don a parka, grab a voltmeter, 
and get helicoptered to the last known location, and dropped off. 
We actually developed a good set of remote diagnostics and self- 
test routines. 


Specifications 


The specifications are derived from the requirements. We need to 
address every requirement, but not include anything else. Every 
specification needs to be traceable back to a requirement, and 
result in a definition of what we're implementing, and a way to test 
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that we have met the requirement. 


When we do the specifications, we are answering the question,. 
“How will the requirements be met?” At this point we should have 
a complete and correct set of requirements, or there will be a lot of 
fixing up to do later. 


We need to determine if some of the requirements are mutually 
exclusive. If so, we have to go back and revisit the requirements. 
You can't have it both ways. We need to cross-reference 
specifications to requirements. There are automated tools to do 
this for larger projects. A piece of paper works well for smaller 
projects. 


Usage scenarios help with defining the requirements. Think about 
how you will use the robot platform. 


Design Reviews are another tool to help us get the specifications 
correct, complete, and in sync with the requirements. Maybe you 
can get a friend or mentor to look over your project, and make 
suggestions. Another set of eyes is useful. 


Our goals in implementation are: 


Functionality. 

Schedule: Time to deliver/time to market. 

Implement the Interface. 

Minimize Non-recurring .costs 

Minimize manufacturing cost. 

A testable unit 

Achieve correct Size, weight, power, energy, color, per 
spec. On time. On budget. 


Reviews 


Design Reviews are another tool to help us get the specifications 
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correct, complete, and in sync with the requirements. You can use 
an independent review team to look over the project, and give 
recommendations. The students should do_ the project 
presentations. There might be a multi-teacher “panel of experts.” 
At this point, technical details are less important than good 
presentation skills. NASA uses a series of reviews along the path to 
a successful project. There might be a Concept and Feasibility 
Review, a Preliminary Design Review (PDR), a Critical Design 
Review (CDR), a Flight Readiness Review (FRR). Each is a 
milestone along the system engineering process. 


Design Decomposition 


There may be multiple ways to implement what we want to do, so 
there are design trade-offs to be made. What functions are done in 
hardware, and which are done in software? Will this be a cpu- 
based design, or a custom architecture in fpga or asic. Can we use 
a System-on-a-chip approach? What is the interface specification — 
what are we talking to, and how are we talking? What are our data 
sources and users? How do we test and verify that the implemented 
system meets the requirements. 


Will the system need to be changed or improved after completion? 
(duh!) Yes, Yes it will. 


Experience counts: To the person with a hammer, all problems 
resemble nails. Are you more software oriented, or more hardware 
oriented? Mechanical? Experience is often a major factor in 
implementation choices. 


Our obvious design goal is to construct an implementation with the 
desired functionality. 


A major design challenge is optimizing multiple design metrics 


simultaneously. Design metrics are a measurable feature of a 
system’s implementation. Common metrics include: 
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e NRE cost (Non-Recurring Engineering cost): The one-time 
monetary cost of designing the system, including tools, 
both hardware and software. 


e Size: the physical space required by the system 


e Performance: the execution time or throughput of the 
system 


e Power: the amount of power consumed by the system (and 
the heat produced) 


e Flexibility: the ability to change the functionality of the 
system easily. 


e Time-to-prototype: the time needed to build a working 
version of the system. Less than a semester. 


e Maintainability: the ability to modify the system after its 
initial release. 


e Correctness. 

e How safe is the system? Can it hurt some one? 
e How secure is the system? 

e Ease of learning and use. 


e Test-ability — can you get enough data to figure out what 
happened when things go bad? 


Design metric interactions are common - improving one may 


worsen others. Are these unintended consequences or blessings in 
disguise? There are trade-offs to be made. This is, after all, an 
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engineering project. Expertise with both software and hardware is 
needed to optimize design metrics. 


System Architecture 


The system architecture has two major components: the software 
and the hardware architecture. You are free to choose either the 
hardware base, the software environment, either, or neither. Keep 
in mind, software is usually hardware dependent. 


The hardware platform architecture, we'll assume for the moment, 
contains a cpu, memory, I/O devices, perhaps a bus to tie the I/O 
together. A single chip solution will give you cpu, memory, and I/O 
in one package, and the bus will be internal to the chip. Multicore 
will give you multiple cpu's to keep busy. The software 
architecture will be constrained by the hardware, and will be 
limited by considerations of performance, testability, maintenance, 
and experience base. 


Hardware and _ software architectures are interlinked by 
considerations based on the requirements; chiefly, speed, 
throughput, memory size, and I/O capacity. 


The hardware platform can be prototyped on an evaluation board 
supplied by the chip manufacturer, or third parties. It will include 
the classical elements of cpu, memory, and I/O, plus clock circuits, 
a power supply, and usually a prototype area. Sometimes, the 
manufacturer will make the net list of the board available, which 
provides a starting point for the final board design. In some cases, 
the prototype board can be used in the final design, if cost and 
schedule is an issue. 


The Processor choice doesn't revolve around operations per 
second, or word width so much anymore. We can get a 64-bit 
processor with a clock in the multi-gigahertz range cheap. As we 
tackle more elaborate problems, even these will seem inadequate, 
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though. We are more focused on integrated functionality, such as 
the number of I/O’s, analog, and interrupts. We need to consider 
power consumption and heat generation as well. 


The implementation software language is a factor, but is 
overshadowed by the your experience. Choose a language you are 
good at, and they hit the ground running. 


The development platform and its requirements is a minor issue, as 
we can assume it runs on a pce. It may be open source, or 
proprietary, and there may be multiple options available. 


The Real-time requirements — this is the hard part, and what 
differentiates embedded from desktop/server. There are two types: 


The operating system is key, and its scheduling policy is critical. 
Desktop operating systems, Windows, Linux, schedule programs 
fairly. Programs get equal access to the resources, and every one 
plays well together. Real-time operating systems are by no means 
fair. They have a priority scheduler, and they make sure the 
important tasks run, even if some lesser tasks never do. . 


Power for the mobile embedded computer can be an issue. The 
systems will not be plugged into the wall. It can be solar powered, 
or wind powered, or a combination (hybrid) system. Investigate the 
quirks of the power source, and see how these can be addressed. 


Keep in mind generated heat depends on power consumption, but 
battery life depends on energy consumption. Energy use is the 
power use, integrated in time. If we generate too much heat, we 
have to dump it somewhere. This might be a good thing. For a 
robotics project going to the Greenland Ice Shelf, we used the 
computer's waste heat to keep the batteries warm. Power 
consumption is proportional to the voltage, squared. We might 
implement toggling; cycling the system on and off: more activity 
means more power. 
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We can reduce power usage by: 


Reduce power supply voltage. 

Run at lower clock frequency. 

Run at lower duty cycle 

Sleep/suspend 

Disable function units with control signals when not in use. 
Disconnect parts from power supply when not in use. 


We can employ static power management which does not depend 
on CPU activity, or we can let the cpu regulate itself. Dynamic 
power management, based on CPU activity, may be built into cpu. 
Keep in mind, though, that dynamic power management takes 
power. Modern CPU's implement multiple low power modes such 
as sleep, doze, etc. 


The system on a chip approach is particularly applicable to 
embedded systems. This approach involves a single chip 
containing a cpu, memory, and I/O, These can be purpose built for 
a specific application and can be implemented in a general purpose 
or generic embedded chip. The chip can contain both digital and 
analog functions. The complexity of the single chip solution 
reflects in the lessened complexity at the board level. Fewer 
external interconnects leads to enhanced reliability. But, it is 
important to realize that the system complexity does not disappear. 
It is at the box, board or chip level. 


Fault Tolerant Design 


In this design approach, a system is designed to continue to operate 
properly in the event of one or more failures. It is sometimes 
referred to as graceful degradation. There is, of course, a limit to 
the number of faults or failures than can be handled, and the faults 
or failures may not be independent. Sometimes, the system will be 
designed to degrade, but not fail, as a result of the fault. Fault 
recovery in a fault-tolerate design is either roll forward, or roll 
back. Roll back refers to returning the system state to a previous 
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checkpointed state. Roll forward corrects the current system state 
to allow continuation. Can you recover your platform if it fails, or 
will it be at the bottom of a lake, or achieving terminal velocity as 
it falls through the atmosphere (toward your neighbor's dog 
house)? 


Redundancy 


Redundancy refers to the technique of having multiple copies of 
critical components. This can refer to hardware or software. This 
increases the reliability of the system. Redundant units can be 
deployed in parallel, such as extra structural members, where each 
single unit can handle the load. This provides what is referred to as 
a margin of safety. An improvement in reliability can be achieved 
by simply adding a second unit in many cases. 


In certain systems that are responsible for safety-critical tasks, we 
might triplicate the critical portion, which, reduces the probability 
of system failure to small, acceptable, levels. 


Of course, if there is a common error in the three units, we have 
not increased our reliability. This situation is referred to as a 
common mode or single point error. Another problem is in the 
voting logic, that makes the decision that an error has been made, 
and switches controllers. At least one satellite launch failed 
because the voting logic made the wrong choice. Redundancy 
carries penalties in size, weight, power, cost, and testing 
complexity. 


Fault isolation allows the system to operate around the failed 
component, using backup or alternative modules. Fault 
containment strives to isolate the fault, and prevent propagation of 
the failure. 


Systems can be designed to be fail-safe, fail-soft, or can be “melt- 


before-fail.” the more fault tolerant that is built into a system, the 
more it will cost, and the more difficult it will be to test. It is 
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important not to increase the complexity to the point where the 
system is not testable, and is “designed to fail.” 


Safety 


Most of what we need to know about Robot Safety can be found in 
Asimov's 3 laws. 


Mobile Robotic systems operate in the real world, and the real 
world can be scary. We need to be aware of the hazards that a 
mobile robot systems can present to others, and the hazards it itself 
can be subject to. We will cover some of those in the section on 
security. A good starting point for robotic safety comes from a 
science fiction book published in 1942 by Isaac Asimov. In his 
short story, Runaround, he introduced his Three Laws of Robotics, 
which have stood the test of time. From their introduction in 
speculative fiction to their influence on industrial systems, they are 
well-thought-out. 


And, they are: 


e A robot may not injure a human being or, through inaction, 
allow a human being to come to harm. 


e A robot must obey the orders given to it by human beings, 
except where such orders would conflict with the First Law. 


e A robot must protect its own existence as long as such 
protection does not conflict with the First or Second Law. 


Print these out and poast them on the wall ov the lab. Asimov went 
on to write many robotics stories, where the effect of the three laws 
were seen in some unusual situations. He actually attributes the 
formulation of his laws as a conversation with John Campbell in 
1940. Asimov always assumed the robots he wrote about had 
inherent safeguards. 


So, based on Asimov's laws as a starting point, we can derive some 
requirements for our robotic systems. First, to not harm a human, 
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the robot must have passive and active safety systems. It must be 
aware of humans within its reach or task space. Speaking as one 
who was pinned to a wall by a 350 pound robot cart, a human- 
sensor is a good idea. If you are operating your quadcopter, it is not 
a good idea to fly it into another person (dog, car...). The flow- 
down safety from the 3-laws continue. Consider safe design, and 
safe operation at the beginning. 


One approach for robot safety is to use a separate safety watchdog 
computer system, with a separate low level hardwire control. The 
separate safety watchdog computer usage did not imply that it is 
the sole repository of safety responsibility. The implementation of 
safety was distributed in the system, from the workstation to the 
robot control computers. At all levels, the system checked the "rea- 
sonableness" of actions before they are carried out. Each safety 
computer monitored both control computers, both joint controllers, 
and both manipulators. The safety computers were implemented as 
a redundant pair, and either could safe the system in a problem sit- 
uation. 


Security 


Are you familiar with the term, robo-jacked? Well, I just made that 
up. But, it refers to a situation in which some one else takes over 
your remote robot. I have had to worry about that. 


All embedded systems have aspects of security. Embedded systems 
on robots operate in an unfriendly world. They are vulnerable to 
variations of hacking, viruses and malware, theft, damage, 
spoofing, and other nasty techniques from the desktop/server 
world. GPS systems can be hacked to provide incorrect location or 
critical time information. Cell phones and tablets are connected 
wirelessly to large networks. A bored teenage hacker in Europe 
took over the city Tram system as his private full-scale railroad, 
using a TV remote. What about the teenager in an internet café is a 
third-world country. Can he take over and play with your robot? 
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Some of these issues are addressed by existing protocols and 
standards for access and communications security. Security may 
also imply system stability and availability. Standard security 
measures such as security reviews and audits, threat analyses, 
target and threat assessments, countermeasures deployment, and 
extensive testing apply to the embedded domain. 


A security assessment of a system involves threat analysis, target 
assessment, risk assessment, countermeasures assessment, and 
testing. This is above and beyond basic system functionality. 


The completed functional system may need additional security 
features, such as intrusion detection and data encryption, All of 
these additional features use time, space, and other resources that 
are usually scarce in embedded systems. 


Virus and malware attacks on desktops and servers are common, 
and an entire industry related to detection, prevention, and 
correction has been spawned. These issues are not as well 
addressed in the embedded world. Attacks on new technology such 
as cell phones, tablets, and GPS systems are emerging. Not all of 
the threats come from individuals. Some are large government- 
funded efforts or commercial entities seeking proprietary 
information or market position. Security breaches can be inspired 
by ideology, money, or fame considerations. The CERT (Computer 
Emergency Response Team) organization at Carnegie Mellon 
University, and the SANS Jnstitute (SysAdmin, Audit, Networking, 
and Security) track security incidents. 


Techniques such as checksums and serial numbers are one 
approach to device protection. Access to the system needs to be 
controlled. If unused ports exist, the corresponding device drivers 
should be disabled, or not included. Mechanisms built into the cpu 
hardware can provide protection of system resources such as 
memory. Co-ordinate closely with your IT person. 


Security has to be designed in from the very beginning; it can’t just 
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be added on. Memorize this. There will be a quiz. 


Mission Definition 


First, Invent a cool project name, maybe an acronym. A key way to 
gain interest is to have a really cool name. Next, have the students 
choose a domain (land, water, underwater, air) and a project. 
(measure this, sample that). 


Weather and environmental observations have vastly improved our 
knowledge of the Earth's weather dynamics, and have improved 
our weather forecast and storm tracking. 


In the system Engineering process, applied to robotics and most 
any engineering project, there are several well defined steps. 


Sensors 


Once we have defined a mission, we can look at the various 
sensors we will need to collect data. We define what to sense, and 
how to sense it. Later, we tackle error sources in sensors, 
limitations, etc. We need to see what interface the sensor needs, to 
hook it up to the embedded computer. It will be either analog 
(continuous voltage) or digital, 2 discrete voltages (such as 0 and 
3.3 v). It the sensor has an analog signal we need to hook it to one 
of the analog to digital inputs on the computer. This will 
automatically convert the analog signal to a digital value the 
computer can work with. Check the allowed voltage range on the 
a/d inputs, so as not to exceed these. Some sensors are passive, and 
some are active, and need power. A temperature sensor might be as 
simple as a variable resistance in response to temperature changes. 
Sensors from the embedded board manufacturers will be designed 
to interface with their boards via an industry standard, such as 12c. 
The vendor will usually provide a pointer to code to read in the 
sensor values, and convert these to “engineering units” - a 
temperature, for example. 


A sensor is a device that measures a physical quantity by changing 
state in response to the stimulation, and producing a signal. It is an 
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analog world. It is rare that we get to interface directly to a digital 
source. Some sensors may indicate one of two states 
(presence/absence) with a simple digital signal that may only 
require voltage level shifting. Other signals, such as a switch 
closure, may appear digital, but require denouncing due to the 
physics of the actual contact, which actually closes and opens 
hundreds of times on activation. This is a form of signal 
conditioning for the sensor. We haven’t yet considered voltage 
levels, current requirements, timing, and all those other real-world 
interfacing issues. We tend to view sensors as a “black-box” 
function, where the output is a valid representation of the applied 
signal. The ugly truth is, sensors are real-world devices that have 
their own non-linearity, parametric shifts, and they tend to respond 
to a lot more than the parameter we are interested in. 


Passive sensors simply collect energy from the sensed phenomena; 
active sensors require power, or an excitation signal. A transducer 
is a device that converts one form of energy to another; a solar cell 
is an example. In the literature, the terms sensor and transducer are 
often used interchangeably. 


All sensors are built to operate within a specified environment that 
corresponds to the temperature limits and other environmental 
conditions of its applied surroundings. Even if other sensors exist, 
they may not satisfy all essential conditions to operate within the 
system, including operating life, sensing range, accuracy, 
redundancy, low energy consumption, environments, mounting 
mechanism, reliability, sensing rate with response time, volume, 
and mass. 


Signal conditioning refers to processing the sensed signal into a 
form from which the digital processor can then extract useful 
information. This may involve amplification or attenuation, analog 
to digital conversion, filtering, format conversion, electrical 
isolation, and other techniques. Noise filtering is a commonly 
applied technique. Sensors exhibit lag and hysteresis, which is a 
difference in offset from one measurement direction to another. 
Bias refers to the situation when the output is not zero when the 
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measured quantity is. There can be dynamic errors, caused by rapid 
change in the input. Drift refers to the fact that, over time, the 
sensor may change output while the input remains steady. 


The physics of the sensor must be considered. A relative humidity 
sensor measures relative humidity, but also temperature. A digital 
compass also reacts to magnetic fields produced by nearby wiring. 
Sensors are inherently non-linear. All of these characteristics must 
be understood and compensated for in software or hardware. With 
smart sensors, this compensation and processing would be 
accomplished within the sensor unit itself. For a simple sensor unit, 
some processing and conditioning must be done within the main 
embedded processor. Consider issues of operating life, range, 
maximum and minimum, accuracy, redundancy, energy 
consumption, heat generation, electromagnetic interference 
generation, electromagnetic interference susceptibility, mounting, 
reliability, sense rate, transient and steady-state response time, 
mass and volume, aging, and mean time to failure when choosing 
Sensors. 


The MEMS, or micro elector mechanical system, uses a chip-level 
integrated circuit technology to provide measurement devices. The 
advantage is that the sensors are made in processes developed for 
semiconductor manufacturer, and are inexpensive to mass-produce. 


A typical accelerator sensor has a small gas-filled chamber with a 
center heating element, and four temperature sensors around the 
edge. A static sensor results in all four temperature elements 
reading the same value. As the sensor is tilted, the higher sensor 
will read hotter. The sensor itself translates temperature differences 
into pulse widths. Some trigonometric calculations are needed to 
resolve angles. It also does not work in zero G. 


These sensors can be used to determine acceleration, tilt, rotation, 
vibration, and other derived values. We have our choice of off-the- 
shelf acoustic and electromagnetic sensors, tactile, force and slip 
sensors, temperature and humidity, specific chemicals, magnetic, 
position (using GPS), and internal state, such as battery state-of- 
charge, derived form an integration of input and output currents, 
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and a good battery model. We might have particle sensors, such as 
smoke detectors, and a pH sensor. The manipulators might require 
angular and extension position in the many axes, and possible 
force sensing. Orientation sensors give us the angle with respect to 
local vertical, or to magnetic north. We can also navigate and 
position with respect to an externally imposed grid, such as the 
terrestrial LORAN or GPS. We can also employ tip and tilt 
sensors. Drop-off sensors are useful for stairs and ravines. From 
touch sensors, we can build a touch map of a surface. Readings 
such as motor stall currents and temperatures of key components 
are useful. 


Sensor data integration is a major topic in robotics. This includes 
not only sensor fusion — the merging of data from different sensor 
into a world-view, but sensor backup to resolve ambiguities. Our 
ability to collect bits exceeds our ability to process them. One 
solution is smarter sensors. Multiple sensors can be used with 
phase discrimination to determine time of arrival of a signal. We 
can do amplitude discrimination to get bearing information (we do 
this with our ears to locate the source of a sound). Sensor 
integration is the backing up of sensors with complementary 
sensors, to eliminate “holes' in the sensed fields. Sensors might be 
passive (listen only) or active, illuminating the target with specific 
energies. 


Actuators 


Actuators provide manipulation and mobility to the system. A key 
metric is the number of degrees of freedom of the subsystem. The 
more degrees of freedom, the more complex the motion, and the 
more complex is the required control. Human tools are designed 
for humans to use. If we don’t want to redesign tools, we design 
the robot manipulator to use human tools. The human arm has 2 
degrees of freedom (DOF) in the shoulder, one at the elbow, and 
three at the wrist. The fingers provide more options. Geometrically, 
6 degrees of freedom (3 rotation plus 3 translation) enable all 
possible motions. But the DOF pairs must be mutually exclusive 
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for this to happen. Redundant DOF’s enable alternate motions or 
paths for the same end point. In a task analysis, we determine the 
number of axes required. This translates to the minimum number 
of DOF’s required. Our baseline is the human arm with 6. 


A manipulator either holds a tool, or is the tool. It can be a 
screwdriver, or a dozer blade. It’s were the work gets done. A 
gripper holds the tool, or the work piece. It can be a simple open- 
close clamp, a vacuum or magnetic grip, an analog of the human 
hand, or a wrapping device like a snake or tail. 


An actuator is the drive mechanism (electric, pneumatic, hydraulic) 
that positions the manipulator. This includes the mobility system to 
move to the work site. The actuator payload is the load capacity at 
the gripper or end effector, measure under static conditions. 
Dynamic conditions must also be considered. Accuracy usually 
refers to cyclic repeatable in class robot systems. We might 
consider accuracy as the minimization of error between expected 
(or commanded) state, and actual. 


The end effector might be a gripper arrangement, a tool, or a tool 
changer. The basic motions are linear and rotational. 


The sensor model for the human skin is one of high but varying 
sensitivity, highest near the fingertips. It has a fast response an 
continuous output. It is flexible and durable, yet self-repairing. It is 
a smart sensor, containing a level of processing. Human skin can 
detect pressure, giving contour information; slippage, the pressure 
across a amp of points; and temperature. This latter property 
allows for a level of materials identification by their thermal 
properties. 


Actuators can have built-in embedded computers. These are 
referred to as smart actuators. They may incorporate a local 
feedback and monitoring loop. IEEE-1451 is a set of standards for 
interfacing smart sensors and smart actuators. The standards cover 
functions, communication protocols, and formats. 
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Power Sources 


More than likely, the robot will operate from batteries. In some 
domains, we might include solar cells to allow recharging during 
the mission. In other cases, we might expect the robot to return to 
its charging base periodically. 


Power management onboard is a big issue. The computer can 
monitor the energy usage from the batteries. We keep track of the 
state-of-charge, which, at the beginning of the mission should be at 
100%. If it gets below, say, 10%, the onboard computer needs to 
take action to shut things down. Even put itself to sleep, as the last 
action. We can have a monitoring program that measures power 
into and out of the battery, and defines a certain state-of-charge. 
Over time, this calculation will show us the degradation of the 
solar cells and the batteries. 


Command and Control 


A hierarchical model for robot control was developed at the 
National Bureau of Standards (NBS), later, National Institute of 
Standards and Technology (NIST) in Gaithersburg, Maryland. 
Initially addressing factory automation, the model has proven to be 
very versatile in addressing a wide variety of tasks. 


The model describes a series of functions, and the data and control 
flow between the functional layers. From the bottom up, the typical 
layers for a hierarchical robot/telerobot control systems would be 
sensor input, servo, primitive command, kinematics, path planner, 
command exec, and user level. With well-defined interfaces 
between each level, development can proceed in parallel, and 
various levels can be generic. 


The NASA/NBS Standard Reference Model for Telerobot Control 
System Architecture was evolved as a model for the implementa- 
tion of advanced control architectures. 
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The NBS architecture is a generic framework in which to imple- 
ment intelligence of a telerobotic device. It was developed over a 
decade as part of a research program in industrial robotics at NBS 
(now. NIST) in which over $25 million was spent. The NBS pro- 
gram involved over fifty professionals and extensive facilities, in- 
cluding robots, a supercomputer, mainframes. minicomputers. mi- 
crocomputers. LISP machines. and AI workstations. This model, 
designed originally for industrial robots. is the mechanism by 
which sensors. expert systems. and controls are linked and operat- 
ed such that a system behaves with some measure of autonomy, if 
not intelligence. 


Systems designed from this model perform complex real-time 
tasks in the presence of sensory input from a variety of sensors. 
They decomposes high level goals into low level actions. making 
real-time decisions in the presence of noise and conflicting de- 
mands on resources. The model provides a framework for linking 
artificial intelligence. expert system. and neural techniques with 
classical real-time control. Sensors are interfaced to controls 
through a hierarchically-structured real-time world model. The 
world model integrates current sensory data with a priori knowl- 
edge to provide the control system with a current best estimate of 
the state of the system. 


NASREM is a generic hierarchical structured functional model for 
the overall system. The hierarchical nature makes it ideal for 
telerobot systems, and for gradual evolution of the system. The 
model also provides a set of common reference terminology, which 
can enable the construction of a database. It defines interfaces, 
which allows for modularization. The model allows for 
evolutionary growth, while providing a structure of the 
interleaving of human:robotic control. 


Getting the data back 


To get our data back from the mission, we need to transmit it back, 
or store it onboard the robot, and retrieve the robot. Storing it 
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onboard is the easiest and cheapest approach. Very large sd cards 
are available cheap. On the other hand, if we don't get the robot 
back for whatever reason, we lose the all data as well. 


Options for sending the data would generally require a radio link. 
Wifi is fairly short range, around 100 feet. Beyond that, we could 
use a relay, perhaps a drone flying over a ground or water surface 
craft. For an underwater mission, we might need a fiber optic 
tether, as water is generally opaque to most radio and light. 


File Systems 

A file system provides a way to organize data in a standard format. 
The file system stores the data, and metadata (data about the data) 
such as date, time, permissions, etc. Some operating systems 
support multiple file systems. The Control Center software will 
take care of storing the incoming telemetry in a file system. It will 
also convert the bits to “engineering unit” if you define the data 
format for it. For example, a temperature sensor will come with a 
graph of the relationship between its reading (in bit) and 
temperature (in Deg F or C). Calibration curve, its called. 


The important thing to keep in mind about about a file systems is, 
don’t reinvent the wheel! There are many good file systems out 
there, and the provide a compatibility across platforms. Most are 
based on the original disk operating system (dos) model. 


The legacy DOS file structure is built upon linked lists. The 
directory file contains lists of files and information about them. It 
uses a 32-byte entry per file, containing the file name, extension, 
attributes, date and time, and the starting location of the file on 
disk. Most digital cameras use this format. 


The File Allocation Table (FAT) is a built map of allocated clusters 
on the disk. A cluster is the default unit of storage. It’s size is a 
trade-off between efficiency of storage, and efficiency of access. A 
size of 256 bytes to 1024 bytes worked well in the early days. Two 
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copies of the FAT are kept by the system, and these are on fixed 
locations of the storage media. 


A directory file has entries for all of the files on the disk. The name 
of the file is in 8.3 format, meaning an 8 character file name, and a 
3-character extension. The extension tells the type of the file, 
executable program, word processing, etc. By DOS convention, 
when a file is erased, the first character of the name is changed to 
the Hex character E5. The data is not lost at this point. If nothing 
else happens in the mean-time, the file can be un-erased, and 
recovered. However, the ES signifies the space the file occupied is 
now available for use. 


Dealing with Failures (Projects, not 


students) 


Even NASA and the Big Aerospace Companies make mistakes. 
Commercial failures tend to be large, expensive, and top news 
material. But, its important to learn as much as possible from 
failures; even to view failures as a learning opportunity. As we say, 
“It may be on fire, but it can serve as a bad example...” This is an 
important idea to keep in mind. We learn more from failures than 
from successes. It is necessary to build the mindset that every thing 
that goes not the way we intended is a learning experience. 
Documentation of failure cases is essential. Convening a group of 
participants and non-participants. to review the failure is a learning 
experience. We don't want to place blame here. The failure case is 
our best learning experience. 


Swarms 
This section describes a different approach to robotics: collections 
of smaller co-operating multi-robotic systems that can combine 


their efforts and work as ad-hoc teams on problems of interest. 


This is based on the collective or parallel behavior of 
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homogeneous systems. This covers collective behavior, modeled 
on biological systems. Examples in nature include migrating birds, 
schooling fish, and herding sheep. A collective behavior emerges 
form interactions between members of the swarm, and the 
environment. 


In Swarm robots, the key issues are communication between units, 
and cooperative behavior. The capability of individual units odes 
not much matter; it is the strength in numbers. Ants and other 
social insects such as termites, wasps, and bees, are models for 
robot swarm behavior. Self-organizing behavior emerges from 
decentralized systems that interact with members of the group, and 
the environment. Swarm intelligence is an emerging field, and 
swarm robotics is in its infancy. 
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Case Studies 


Greenland Ice Pack Rover (Grover) 


For our Greenland Rover Project, the payload was a unique ice- 
penetrating radar, developed by a scientist expert in such things. 
We integrated it on the Rover system. 


NASA/GSFC Summer Engineering Robotics Boot Camp 


This program ran for eight years under the guidance of Mike 
Comberiate (NASA-Mike). It brought undergraduates, graduate 
students, even some high-schoolers together for an intense 8-week 
session at Goddard. It was an expansion of the 25-year program 
COOL-SPACE, Communications Over Obscure Locations, Special 
Purpose Advanced Communications Equipment, which provided 
INTERNET access to Antarctica via satellite. In the 2011 session, 
there were over 800 applicants, down-selected to about 40. 
International students were accepted. The level of energy and 
achievement is high. Recent projects have involved tracked 
vehicles in Antarctica in 2008, an autonomous vehicle for 
Greenland ice sheet exploration, and an autonomous meteorite 
finder for Antarctica. At the conclusion of the summer program, it 
is not unusual for students to be hired by NASA or a Contractor. 
The Program was targeted at STEM careers, with multi- 
discliplinary engineering. 


This project is one in which the author had direct, hands-on 
experience. It was a project conducted over several summers at 
NASA/GSFC, by student interns. The concept was to have an 
autonomous vehicle collect data from an ice-penetrating radar units 
over large areas. The instrument was developed under an NSF 
Grant, and had been operated by two persons on skis, or by one 
person on a snowmobile. The Grover project was derived from a 
series of tracked sensor packages deployed in Antarctica, and 
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conducted by a international team of 40 graduate and 
undergraduate students over several summers. The Program, 
sponsored by the GSFC Office of Education, was termed the 
Summer Robotics Boot Camp. The 40 students were selected from 
hundreds of applicants, and lead by a series of Mentors, chosen 
from NASA Civil Service and Contractor personnel. 


The original Antarctic Rovers were small commercial tracked 
vehicles. The Grover was an extension to this, using a custom built 
aluminum chassis. It was powered by electric motors, supplied by 
lead acid batteries. Other battery technologies were too expensive. 
Waste heat from the computers was used to keep the batteries 
warm. The batteries were charged by large solar panels, but due to 
the low sun elevation at high latitudes, a hybrid wind turbine 
systems was added. Winds off the polar ice cap had essentially no 
obstruction before reaching lower latitudes, and blow continuously 
down the ice sheet. 


The primary computational resource was a pc-class dual-core Intel 
motherboard. This interfaced to the instrument, formatted, and 
stored the data in a solid state drive. The volume of data collect 
was about 4-6 gigabytes per day, and the onboard storage system 
was sized for 3 months of autonomous operation. Communication 
with the autonomous vehicle was via Iridium satellite modem, with 
text messages. This was adequate for command uplink, and status 
message downlink. For testing, the Grover included wifi for a 
local area network mobile connection. 


The Grover unit had a GPS for location, encoders on each motor to 
track distance traveled, obstacle avoidance sensors, a compass 
sensor, battery and motor current and voltage sensors, sun sensors, 
and distributed temperature sensors. 


The main computer ran an application in the Python language, and 
various distributed embedded controllers based on the Arduino 
architecture were used. There was a watchdog computer for main 
computer problems, temperature, and anomalies. A reset could be 
commanded over the Iridium link. 
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The unit could be controlled directly with a wired pendant for 
testing, and through the wifi or Iridium link. It could also operated 
in autonomous mode, following predefined patterns. 


During field tests of the unit at NASA's Wallops Flight Facility in 
2011, a quadcopter unit was used to make a video of the vehicle's 
performance from a “god's eye” view. It was later realized this 
capability could be used operationally, with the rover and the 
copter operating cooperatively. The rover would provide a landing 
spot and battery recharging station for the copter, and the copter 
could scout ahead of the rover for ice fissures, and areas of 
potential interest. This would provide a level of cooperation 
between the two systems. The rover is based on the previous 
Curiosity design, with different instruments. 


This approach was adopted by JPL for their Mars 2020 lander. It is 
going to the Jezero crater. It will be accompanied by the Mars 
Helicopter Scout, a solar powered unit with an (Earth) weight 
around four pounds. It's primary prupose is to scout out in fron of 
the rover. It is limited to about 3 minutes of active flight per day. 
Helicopters don't fly beyond 40,000 feet on Earth, but near the 
surface of Mars, the atmospheric density is more like Earth's at 
100,000 feet. The helicopter will have twin blades, rotating more 
than 10 times as faster than a unit on Earth. 


Performance in field tests is seen in the excerpt from the Test 
summary, 432011: 


“The motors routinely produced enough power and torque to move 
the robot at max speed (1.2 mph) in all terrain conditions (wet 
sand, hard packed sand, and soft dry sand). The Solar Arrays are 
about 13% efficient. In partly cloudy conditions with Sun almost 
overhead, the sunlit panels produced an average 216 W (with both 
panels). The other side produced an average 65 W, from non- 
direct sunlight and from sunlight reflected off the ocean and sand. 
The average wind Speed was 13 mph, which is typical of what we 
anticipate for the Greenland Ice Summit. This produced an 
average of 78 W from two wind turbines There was absolutely no 
indication of any tipping of the vehicle even in 40 mph gusts, 
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which we have also experienced with it previously. The vehicle is 
very stable and durable and it has enough torque as currently 
geared, to drag a 225lb load through the sand behind it with an 
additional 100W of power. The load for this chassis design without 
the Instrument was 360W in the Driving mode and 50W in Idle 
mode. We anticipate another 100W worst case for the Instrument 
operational mode. 


The tests performed on the power systems prove that GROVER 
will have over a 30% duty cycle in nominal Greenland Summit 
conditions, for the fully loaded Instrument operational mode. We 
are now designing a lighter version of the vehicle with more 
efficient solar arrays and batteries, which we expect to be 200lbs 
lighter and will take 100W less power to operate. Our goal then is 
to get above 50% operational duty cycle for nominal conditions. 
Note that on the beach under conditions of 10mph wind and clear 
sunshine, we were power positive, so we have justification for 
confidence that we can achieve a minimum of 50% duty cycle in 
nominal Greenland conditions. This is akin to operating in the 
daytime only around here. Also, we can easily adjust the gear 
ratios to drive the vehicle faster if desired.” 


The engineering prototype of Grover can be seen at the 
NASA/Goddard Space Flight Center visitors Center. Only the 
frame, motors, and solar panels are present, as the electronics have 
been removed. 


Lunar rover Concept 


This project was conducted during a summer Cubesat program for 
undergraduate engineering exchange students from Brazil, at 
Capitol Technology University in Laurel, MD. 


The challenge was to construct a Rover vehicle to explore the back 
side of the moon, during its 2-week sunlight period. The project 
included a communications relay with Earth in lunar orbit, a 
lander/base and multiple Rovers. Different students worked on 
different portions of the mission. This section will discuss only the 
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rover units. 


These were wheeled units, with an Arduino-based microcontroller 
the UNO R3/Mega2560/Mega2560. It included a sensor shield, a 
4WD Mobile Platform, and a Dual H-Bridge Stepper Motor 
Driver. 


Science Objectives: Obtain and return to Earth imaging and 
environmental data from defined targets of interest on the Moon. 


We baselined multiple rover units, around 4-6. We consider four of 
these are primary, with 2 spares. The rovers probably be in 
communication with the lander/base, at least in the sense that they 
would receive a beacon signal, so they could get back. There is no 
infrastructure like Earth's GPS system for Navigation, so the 
Rovers would use dead reckoning. From Lunar Reconnaissance 
Orbiter (LRO ) lunar maps, interesting targets would be uploaded 
to the rovers, via the orbital relay and lander/base. To return, the 
rovers would essentially reverse their path, which is stored in their 
memory. This is not always guaranteed to get you back home. 


The rovers will have a standard suite of sensors, including video, 
and each will carry a particular or specialized sensor such as a 
magnetometer. The rover with a specific specialized sensor can be 
dispatched to a selected target area of interest. It is even feasible to 
include a rock drill or sample collection scoop. The rovers will be 
able to operate as teams, giving simultaneous observations from 
different locations, or supplementing individual sensor suites. 


The rovers will store their science and housekeeping data onboard, 
and upload it to the lander when they return. Upon return, they go 
inside the lander and are guided by rails to the data connection and 
the charging connection. The rover resembled a Cubesat on a 
wheeled platform. The Cubesat architecture, although designed for 
space, is a good modular architecture for a lot of domains. The 
rover will operate independently when deployed outside the 
lander. 
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The Rover architecture was prototyped and testing during the 
Summer of 2016. We were able to take the Rover to the National 
Institutes of Science and Technology (NIST) in Gaithersburg, MD, 
for testing It was put through its paces in the NIST Robotics Test 
Facility, Bldg. 207. 


This facility implements the Standard Test Methods for Response 
Robots. As such, it provides a series of environments and terrains 
that have been used for the DARPA Robotics Challenge, STEM 
robotics, and the RoboCupRescue Rapidly Manufactured Robot 
League (RMRL), for emergency responders. The Lunar Rover 
Cubesat used the Aerial Test Methods floor, as well as the several 
of the mobility test environments. 


Data recorded by the rover was sent back to a laptop workstation 
via wifi and recorded, as well as being displayed in real time. Two 
different types of tires were used. The finding was that the larger 
tires increased ground spacing, but the motors or battery system 
could not support the increased tire size. The edge detection 
systems of the robot was tested at a drop-off, and stopped the robot 
successfully. Generally, the robot's algorithm for navigation 
changes when faced with an obstacle performed adequately. The 
project is continuing as a collaborative Internet effort. 


Atmospheric satellites 


Blimp and solar powered long duration aircraft can serve as 
atmosats, operating on solar power for weeks, months, or years at 
altitudes of 60,00 feet or more. This is currently a research area, 
but applications include severe weather monitoring, forest fire 
detection and mapping, and data gathering from very remote 
locations of the globe. The data complements that from orbiting 
satellites. These vehicles can take advantage of the GPS 
infrastructure for location, and relays for communications. Smaller 
units flown at lower altitudes as student projects use cell phones as 
the communications link. 
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Volcano Explorer 


The Robotics group at Carnegie-Mellon University is headed by 
the famed Red Whittaker, who lead the CMU team to win the 
DARPA Challenge. One of his many projects was a mobile 
platform, Dante, designed to enter an active volcano. 


In December of 1992, Dante and the support team ventured to 
active Mount Erebus in Antarctica, 12,450 feet high, and about 800 
miles from the pole. Erebus is important enough that manned 
attempts were made to enter the caldera, all unsuccessful. How 
much the volcano contributes to the hole in the ozone layer above 
Antarctica is not known. The ozone layer blocks ultraviolet light 
from the sun, and is critical to the continuance of life on Earth. The 
robot made the descent to the crater floor, some 850 feet from the 
top. Here it took temperature measurements, and gas samples. 
Erebus tends to erupt in a minor fashion several times a day. This 
was a NASA Project, supported by the National Science 
Foundation. The temperature proved to be around 1,100 degrees 
from the corrosive gases vented by the volcano. 


Dante is a six-legged walking robot, weighing close to 1000 
pounds, and connected to the support team outside the volcano by 
a tether to provide power and data, and possible retrieval if the 
robot becomes disabled. 


In August of 1994, an upgraded version of the robot, Dante 2, 
explored the active Alaskan volcano, Mount Spurr. This is located 
some 80 miles west of Anchorage. The descent into the caldera 
was 650 feet. The robot was monitored from a control facility in 
Anchorage, via a satellite link, providing a live video feed.. Dante- 
2 was bulked up at 1,700 pounds, having been redesigned based on 
the earlier robot's lessons-learned. It was able to explore 
underneath a rock ledge, that had blocked an aerial view of a part 
of the crater. After successfully completing its mission, the robot 
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walked its way out of the crater. 


CMU Rovers have also been used in mine mapping. A rover called 
Groundhog went into an abandoned Pennsylvania coal mine and 
sent out live video to a conference on Mine Safety in 2002. They 
primary usage for the robots is seen as mapping. After initial tests, 
the concept of a wheeled rover was reconsidered, and an 
amphibious robot will be designed. This is because old mines are 
frequently flooded. 


Reference: 
Byron Spice (2002-10-29). "CMU tries out new mine-mapping 
robot" Pittsburgh Post Gazette. 


Archaeology applications 


In large areas of interest, such as deserts and jungle, flying drones 
can be a major help in getting the big picture, locating areas of 
interest to explore. Imaging from orbit is good for a start, but 
doesn't necessarily include enough detail. Local exploration by 
flying drones is the next step. 


One area that has challenged amateur archaeologists is the search 
for Genghis Khan's tomb. When the founder of the Mongol Empire 
died in August of 1227, his body was interned in a hidden location 
on the steppe's of Asia, according to the traditions and customs of 
his tribe. His body was reported to have been returned to 
Mongolia, possibly to his birthplace. Supposedly, the funeral escort 
killed every one with a knowledge of the location. 


The interest in finding his grave site is high, and there is essentially 
a cult interest in him, as well as intense national pride in Mongolia. 


Mongolia has a lot of remote surface area to cover. 


An international effort, using crowd sourcing, is termed, “The 
Valley of the Khan Project.” Starting with armchair explorers 
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sifting through large amounts of online satellite imagery by 
volunteers, a ground team then explores likely areas using a small 
aerial hexcopter. On-site teams use ground penetrating radar. This 
Project is sponsored in part by the National Geographic Society. 


References: 
"Palace of Genghis Khan unearthed". BBC. October 7, 2004. 


http://www.nationalgeographic.com/explorers/projects/valley- 
khans-project/ 


http://exploration.nationalgeographic.com/mongolia/content/2 | st- 
century-approach-ground-surveying 


Flying drones have also been used to locate and identify sites of 
archaeological interest in Peru since 2013. Due to performance 
issues at altitudes above 12,000 feet in the Andes, drone blimps 
have more recently been used. The collected data is used to 
compile 3-d maps that are then used to guide field surveys. These 
have found application in Mayan city sites in dense jungle in 
Central America as well. 


Since 2013 drones have flown over at least six Peruvian 
archaeological sites, including the colonial Andean town Machu 
Llacta 4,000 metres (13,000 ft) above sea level. 


NASA Rovers in Antarctica 


NASA sponsored the Robotics Institute at Carnegie Mellon 
University to build the Nomad Rover, a 4-wheeled, 1,600 pound 
autonomous explorer. It was deployed in Antarctica in the year 
2000. It's job is to find meteorites. It turns out, a lot of the 
meteorites found in Antarctica are from Mars, based on their 
chemical composition. Nomad is doing the a similar job on Earth 
to what the Mars Rovers are doing on Mars. 
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Nomad is equipped with a laser rangefinder, high resolution 
cameras, onboard computer, satellite data link, and a gasoline- 
powered generator. It is looking for meteorites on the ice with a 
specific set of characteristics. If one is detected, it navigates to the 
target for a closer look. It has an arm with a camera and 
spectrometer, as well as a metal detector. If the rock meets the 
profile of being a potential meteorite, the GPS location is logged. 
The robot does not collect samples, but does sort through rock 
fields for items of interest. 


A rock the size of a potato (Allan Hills 84001) found in Antarctica 
in 1984 definitely came from Mars, and had chemical and fossil 
evidence of life. It is yet to be proven whether this definitely shows 
the past presence of life on Mars. 


A friend and past-professor in the Applied Space Sciences 
Department at Carnegie Mellon University (with 5 advanced 
degrees) has proved that meteorites from Mars accumulate in 
Antarctica. I won't stress you with the math. 


Weather observing robots 

Flying through Hurricanes is routinely done by a dedicated cadre 
of pilots and crew, operating from southern Florida. The in-situ 
measurements they provide are invaluable to tracking and early 
warning of these storms. It is also incredibly dangerous. NOAA is 
now using unmanned instrumented drones in this role. They are 
expendable, have a longer working time on target, and provide 
more data. These units may eliminate or minimize the manned 
missions. 


Lorax 

Lorax is a project of CMU's Robotics Institute, and the name 
stands for Life on Ice: Robotic Antarctic Explorer. This will be an 
autonomous system to survey the population of microbes on the 
Antarctic ice sheet. Such extremophiles are known to exist on 
Earth. A team from Colorado University in Boulder found 
microbes thriving on the high slopes of Andean volcanoes, 


70 


surviving heat, ultraviolet radiation, and noxious gases. Bacteria 
are often seen in the soil after a glacier retreats. These 
environments are not much different than those on Mars. This is a 
NASA sponsored project. 


One goal of this project is autonomous operation for a month. It 
uses both solar power and wind power. A model was tested in 2005 
on a frozen lake bed in New Hampshire. It successfully traversed 
14 kilometers autonomously, and returned to its starting point. It is 
a 4-wheeled vehicle. 


And in conclusion, 


The STEM program is essential to the United States' and the 
World's dominance and application of advanced technologies. I 
can't say for a fact that every nation has Stem programs, but a lot 
do. Along the way, students have learned a lot about engineering in 
general. Most importantly, we have gotten them interested and 
engaged. Even if they never do another engineering project in their 
life, they will understand the process, its applications, and its 
limitations. Some of them will go on to find solutions to problems 
we are not yet aware of. Maybe these will be your students. 
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Aerostat — flight system deriving lift from buoyancy. 

Aerobot — aerial robot 

Agent — an autonomous entity (hardware/software) which is goal- 
seeking. 

ANTS — Autonomous Nano Technology Swarm 

Api — applications program interface 

Arduino — small embedded systems architecture. 

ASIC — application specific integrated circuit. Specific hardware. 

Atmosat — platform operating at high altitude in the atmosphere, 
for extended periods. 

AVR — a family of microcontrollers from Atmel. Corp, 

BIOS — Basic I/O system — initialization. 

BIST — built-in self test 

Bit — smallest unit of binary information. Two states. 

Bluetooth — a short range radio standard for data. 

BSD - Berkeley Systems Distribution (of Unix) 

BSP — board support package — customization code for specific 
hardware. 

Byte — collection of 8 bits. 

C —a programming language. 

CAN -— controller area networm, by Bosch. 

Cubesat — small satellite that can be developed by schools or 
individuals (standard) 

CMU — Carnegie Mellon University. 

Codec — coder/decoder 

copyleft — license for open source software 

Cpu — central processing unit. 

DARPA — Defense Advanced Research Projects Agency. 

De — direct current 

DOF -— degrees of fredom 

Drone — unmanned aerial vehicle. 

DSP — digital signal processor 

dutycycle — percentage of “ON” in an on-off cycle. 

eeprom — electrically erasable programmable read-only memory. 
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Mostly superseded by flash. 

Enviro-bot — a small mobile robotic platform for environmental 
monitoring. 

Ethernet — a networking protocol; wired or wireless. 

Flash — a type of non-volatile memory. 

FPGA — field programmable gate array. 

Gbytes - 10° bytes. 

GHz - 10° hertz 

gnu — recursive acronym — “gnu is not unix.” 

Gpio — general purpose input output 

GPL — gnu public license (open source) 

GPS — global positioning system, series of navigation satellites. 

Grover — Greenland Rover. 

GSGC — Goddard Space Flight Center, lead NASA Center for 

Earth observation. 

H-bridge — a power circuit for dc motors, allowing motion in both 
directions. 

HDMI - High Definition Multimedia Interface 

Hexcopter - a small aircraft with six small horizontal rotors, like a 
helicopter. 

Homeostasis — a self-moniotoring, self-regulating system. System. 
you, for example. 

Http — hyper-text transfer protocol. 

IDE — Integrated Development Environment (toolset) 

IoT — Internet of Things. 

Isa — instruction set architecture. 

Java — a programming language. 

Kbytes — 10° bytes. 

Lidar — radar, using light. Same thing, different frequency. 

Linux — open source operating system; unix-like 

LioP — lithium polymer battery technology. 

Lorax — Life on Ice Robotic Antarctic Explorer — CMU project. 

Malware — malicious software. 

Mbytes — 10° bytes. 

MEMS - microelectronic mechanical systems — producing 
mechanical systems such as gyros using microelectronics 
fabrication technology. 
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MER — Mars Exploration Rover. 

Metadata — data about the data. Date, time, modified? Etc. 

microcontroller — microprocessor plus memory and I/O. 

mips — millions of instructions per second. 

Moore's Law — Empirical law that technology doubles in 

complexity and capability in about 18 months 

MSL — Mars Science Lab. 

Multicore — computer architecture with multiple processors on one 

chip. 

Mutex — a mutual exclusion mechanism in hardware (traffic light) 

or software. 

NASA — U. S. National Aeronautics and Space Administration. 

NOAA - U. S. National Oceanographic Atmospheric 

Administration. 

NSF — U. S. National Science Foundation. 

Pc — personal computer 

PWM - pulse width modulation; used for de motor speed control. 

Python — programming language; large man-eating snake. 

Quadcopter — a small aircraft with four small horizontal rotors, like 
a helicopter. 

Regolith - layer of unconsolidated rocky material covering 
bedrock. 

Rov — remotely operated vehicle. 

RS-232 — standard for serial data commuication, typically +/- 12 
volts. 

Sata — a serial disk interface standard. 

SatCom — satellite communications. 

Seu — single event upset in electronics, usually due to radiation. 

SMART — Super Miniaturized Addressable Reconfigurable 

Technology. 

SRAM - static random access memory 

Stiction — static friction, getting started from a dead stop. 

TTL — transistor-transistor logic, commonly operating at 5 volts. 

UART - universal asynchronous receiver transmitter. 

UAS — unmanned aerial system. 

UAV — unmanned aerial vehicle, or remotely piloted aircraft, or 
drone. 
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URL — uniform resource locator. Used as a reference to a resource 
on the Internet. 

Usb — universal serial bus, a communications standard. 

UUV — unmanned underwater vehicle.. 

WiFi — short range radio-based networking, to about 100 feet. 
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